Data Access Control: Principles Locate
This chapter describes the entity access control mechanism, which defines permissions for users and groups to access structures in BEA AquaLogic Service Registry
There are two types of user groups: public and private. Both public and private groups are visible to all users in the registry, meaning that all users are able to see which groups exist. Public and private groups differ in that members of public groups are visible to all users of the registry whereas members of private groups are visible only to the owner of the group.
![[Note]](../images/note.gif) | Note |
|---|---|
There are other permissions in BEA AquaLogic Service Registry used to control access to APIs and their operations. API permissions are relations between the user or group and operation only. Please see Permissions: Principles in the Administration Guide for details. | |
Permission in this chapter is limited to Data Access Permission - ACL permission.
We use the following terms with regard to ACL permissions:
Party A user or group of users
Core Structure One of the major UDDI data structures: businessEntity, businessService, bindingTemplate or tModel
Action An operation: "find", "get", "save", or "delete" on the entity plus special action "create", which means to save sub-entities. (For example, a user with the "create" permission on a businessService can save new bindingTemplates under the businessService, but can not update whole businessService.) Note that the "create" permission makes sense only on businessEntity and businessService, because bindingTemplates and tModels have no sub-entities.
Standard UDDI access control defines that only the owner of a UDDI core structure can update or delete it. Every user can find or get the structure (with the exception that deleted/hidden tModels are visible for get_tModelDetail but not for the find_tModel operation). ACLs (Access Control Lists) added to a UDDI entity can override standard UDDI access control as there are several cases in which standard access control is not sufficient.
Examples:
When a Web service is under construction, its UDDI representation (businessService and bindingTemplate) should be visible only to members of the development team. Arbitrary users should not be able to obtain it in the result set of get_serviceDetail or find_service operations. Moreover, a get_businessDetail or find_business operation result, which includes a superior businessEntity, should not give away the existence of the businessService.
On the other hand when the server (where the service prototype is running) goes down, the administrator should be able to deploy the Web service on another server and repair the service endpoint in the accessPoint within its bindingTemplate, despite not being the owner of the bindingTemplate.
Explicit Permissions Locate
Explicit permission gives (positive permission), or revokes (negative permission), access rights to a party to process an action on a specified entity.
Explicit permissions are saved with the entity as special keyedReferences in the categoryBag. For more information, please see Setting ACLs on UDDI v3 Structures and Setting ACLs on UDDI v1 and v2 Structures below.
Permission Rules Locate
When no explicit permission is set for the find/get action on an entity, everyone can find/get it. When no explicit permission is set for the save/delete action on an entity, only owner of the entity can save/delete it. This is a standard UDDI access control. When an explicit Permission is set for an action, a completely different access control is used which is defined by the following rules:
Owner always has full control The owner can always process an operation over an owned entity, even if the permission is explicitly revoked.
Negative permission for a user overrides positive permission for a user. Example: User U has explicit positive permission on businessEntity BE for the get action. However, if U also has explicit negative permission on BE for action get, then an attempt to process get_businessDetail by user U on the BE will fail.
Negative permission for group overrides positive permission for group. Example: User U has belongs to groups G1 and G2. Group G1, has explicit positive permission on the BE for action get. Group G2, has explicit negative permission on the BE for action get. Because of this negative permission, any attempt to process get_businessDetail by user U on the BE will fail.
Permission for user has more weight than permission for group Example: User U has explicit positive permission on businessEntity BE for action get. Group G, to which U belongs, has explicit negative permission on the BE for action get. User U can process get_businessDetail on the BE, even though U belongs to group G.
The owner of an entity can always process get_XXX on a direct sub-entity Example: User U1 owns businessEntity BE. U1 (as owner) grants "create" permission to user U2. Then U2 saves new businessService BS with bindingTemplate BT under BE. When user U1 executes get_businessDetail, U1 obtains BE with BS but without BT, because BT is not a direct sub-element of the BE.
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.
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 save/delete an entity can do this despite not having sufficient privileges on sub-entities.
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.
Composite Operations Locate
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.
Pre-installed Groups Locate
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 BEA AquaLogic Service Registry users.
- system#everyone
Holds all users of BEA AquaLogic Service Registry (both users who have and who do not have a BEA AquaLogic Service Registry account, authenticated and non-authenticated). If this group is used, all users always have the specified permission to the associated data.
- system#registered
Holds all authenticated BEA AquaLogic 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.
- system#intranet
Holds users who access BEA AquaLogic Service Registry via a local intranet. (This group is reserved for a future release. There is no implementation behind it as of BEA AquaLogic Service Registry 6.5)
ACL tModels Locate
ACL permissions are represented as tModels as detailed below:
| ACL Permission | v3 tModelKey | v2 tModelKey |
|---|---|---|
| find allowed | uddi:systinet.com:acl:find-allowed | uuid:aacfc8e0-dcf5-11d5-b238-cbbeaea0a8d4 |
| find denied | uddi:systinet.com:acl:find-denied | uuid:ced3c160-dcf5-11d5-b238-cbbeaea0a8d4 |
| get allowed | uddi:systinet.com:acl:get-allowed | uuid:f9977a90-dcf5-11d5-b238-cbbeaea0a8d4 |
| get denied | uddi:systinet.com:acl:get-denied | uuid:09e202d0-dcf6-11d5-b238-cbbeaea0a8d4 |
| save allowed | uddi:systinet.com:acl:save-allowed | uuid:19885bd0-dcf6-11d5-b239-cbbeaea0a8d4 |
| save denied | uddi:systinet.com:acl:save-denied | uuid:2a25e610-dcf6-11d5-b239-cbbeaea0a8d4 |
| delete allowed | uddi:systinet.com:acl:delete-allowed | uuid:37f44ac0-dcf6-11d5-b239-cbbeaea0a8d4 |
| delete denied | uddi:systinet.com:acl:delete-denied | uuid:4e51d8f0-dcf6-11d5-b239-cbbeaea0a8d4 |
| create allowed | uddi:systinet.com:acl:create-allowed | uuid:5bc32980-dcf6-11d5-b239-cbbeaea0a8d4 |
| create denied | uddi:systinet.com:acl:create-denied | uuid:6d0be7e0-dcf6-11d5-b239-cbbeaea0a8d4 |
Setting ACLs on UDDI v3 Structures Locate
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>
Setting ACLs on UDDI v1/v2 Structures Locate
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).
For example, user demo_john can save (update) following businessEntity even if he is not the owner:
<businessEntity ...>
...
<categoryBag>
<keyedReference tModelKey="uuid:19885bd0-dcf6-11d5-b239-cbbeaea0a8d4"
keyName="user" keyValue="demo_john"/>
...
</categoryBag>
</businessEntity>
| Note |
|---|---|
ACL permissions cannot be set on the bindingTemplate structure because this structure has no categoryBag in UDDI v1/v2. | |