Explicit Permissions Data Access Control: Principles

Motivation: This rule ensures that the owner of an entity will see all direct sub-entities. The number of sub-entities is limited. By default, a user can save only one businessEntity, four businessServices per businessEntity, two bindingTemplates per businessService and 10 tModels. Suppose that user U1 has businessEntity BE. User U2 can save businessServices in BE permission create on BE. If U2 has already saved four businessServices under BE, user U1 cannot, therefore, save a new businessService. Therefore, the owner of an businessEntity should see why the limit is reached. 6. Delete and Save positive permissions are inherited from parent entities and override negative permissions on sub-entities Example: User U has delete permission on businessEntity BE. Then U can execute the delete_business operation, which deletes the BE with all its businessServices and bindingTemplates, even if some of these sub-entities have negative permission for deletion by the user U. Motivation: Sub-entities can not survive parent entity deletion. This rule ensures that a user who can savedelete an entity can do this despite not having sufficient privileges on sub-entities. 7. To perform update by save_XXX operation, it is necessary to have both save and get permissions Example: User U1 has save and get permissions on businessEntity BE, but he is not the owner. User U2 owns the BE and saves businessService BS1, which has get permission for U1, and businessService BS2 without any permissions. Both BS1 and BS2 are created under BE. U1 gets BE with only BS1 and updates BE in this way: U1 can add a category and save BE again without BS1. In fact, when BE is updated, BS1 is deleted but BS2 remains. Example: User U1 owns a businessEntity BE. The user U1 defines the explicit get allowed permission to user group G1. Everyone can find the BE, because there is no explicit permission for find and therefore the standard UDDI access control is used. On the other hand, only user U1 as the owner and all users from group G1 can get the BE.

5.1.3. Composite Operations

BusinessService BS can be moved from one businessEntity BE1 to other businessEntity BE2. By performing the save_service operation on BS, where BS has updated businessKey to point to the BE2. To perform this action, the party must have permission to save BE1, BE2, and BS, because all these entities are changed. Similarly bindingTemplate BT can be moved from businessService BS1 to businessService BS2. The party who moves it must have save permission on BS1, BS2 and BT. BusinessService BS hosted in businessEntity BE1 can be projected into businessEntity BE2. The party who projects BS must have save permission on BE2.

5.1.4. Pre-installed Groups

ACL logic considers some special pre-published abstract groups during permission evaluation. These abstract groups allow a publisher to give a permission to a specific set of Oracle Service Registry users. systemeveryone Holds all users of Oracle Service Registry both users who have and who do not have an Oracle Service Registry account, authenticated and non-authenticated. If this group is used, all users always have the specified permission to the associated data. systemregistered Holds all authenticated Oracle Service Registry users. Every user who is authenticated that is, who has an account and has logged into the registry is a member of this group. If this group is used, all authenticated users always have the specified permission to the associated data. Page 207

5.1.4. Pre-installed Groups