Permission Rules 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

systemintranet Holds users who access Oracle Service Registry via a local intranet. This group is reserved for a future release. There is no implementation behind it as of Oracle Service Registry 11.1.1

5.1.5. ACL tModels

ACL permissions are represented as tModels as detailed below: v2 tModelKey v3 tModelKey ACL Permission uuid:aacfc8e0-dcf5-11d5-b238-cbbeaea0a8d4 uddi:systinet.com:acl:find-allowed find allowed uuid:ced3c160-dcf5-11d5-b238-cbbeaea0a8d4 uddi:systinet.com:acl:find-denied find denied uuid:f9977a90-dcf5-11d5-b238-cbbeaea0a8d4 uddi:systinet.com:acl:get-allowed get allowed uuid:09e202d0-dcf6-11d5-b238-cbbeaea0a8d4 uddi:systinet.com:acl:get-denied get denied uuid:19885bd0-dcf6-11d5-b239-cbbeaea0a8d4 uddi:systinet.com:acl:save-allowed save allowed uuid:2a25e610-dcf6-11d5-b239-cbbeaea0a8d4 uddi:systinet.com:acl:save-denied save denied uuid:37f44ac0-dcf6-11d5-b239-cbbeaea0a8d4 uddi:systinet.com:acl:delete-allowed delete allowed uuid:4e51d8f0-dcf6-11d5-b239-cbbeaea0a8d4 uddi:systinet.com:acl:delete-denied delete denied uuid:5bc32980-dcf6-11d5-b239-cbbeaea0a8d4 uddi:systinet.com:acl:create-allowed create allowed uuid:6d0be7e0-dcf6-11d5-b239-cbbeaea0a8d4 uddi:systinet.com:acl:create-denied create denied

5.1.6. Setting ACLs on UDDI v3 Structures

In UDDI v3, explicit ACL permission is saved in a special keyedReferenceGroup having the tModelKey uddi:systinet.com:acl . This keyedReferenceGroup can contain only keyedReferences to ACL tModels. Only the terms user and group are allowed in the included keyName, and the keyValue must contain the name of the user or group according to keyName value. For example, user demo_john can save update following businessEntity even if he is not the owner: Example 1. Setting ACLs - v3 businessEntity xmlns=urn:uddi-org:api_v3 ... categoryBag ... keyedReferenceGroup tModelKey=uddi:systinet.com:acl keyedReference tModelKey=uddi:systinet.com:acl:save-allowed keyName=user keyValue=demo_john ... keyedReferenceGroup categoryBag businessEntity

5.1.7. Setting ACLs on UDDI v1v2 Structures

Under versions 1 and 2 of UDDI, explicit ACL permission is saved as a special keyedReference in the categoryBag. This keyedReference refers to one of the tModels representing ACL permissions. Only the terms user and group are allowed in the included keyName and the keyValue must contain the name of the user or group according to the keyName value. Page 208

5.1.7. Setting ACLs on UDDI v1v2 Structures