Approvers Actions Approval Process

ApproveReject Request To approve or reject an approval request: 1. Click on the Approvals to Administer link under the Tools main menu tab. The page shown in Figure 39 will appear. Figure 39. View Requests to Administer 2. If you click on the request name, you will see the requests detailed information including a list of entities the requestor wants to be promote. To approve or reject the request, click on an appropriate button icon in the Action column. If you click Approve, the page shown Figure 40 will appear. Page 203 ApproveReject Request Figure 40. Approve Request 3. You can review all entities in the request, see request history, and optionally enter a message for the requestor. Once you click Approve, an email notification will be sent to the requestor and entities listed in the request will be promoted to the discovery registry. View Approval History Approvers have the ability to see all approval requests they have approved or rejected. To access the approval history, click on the Approval Admin History link under the Tools main menu link. The Approval Admin History page shown in Figure 41 will appear. Page 204 View Approval History Note Approvers are not allowed to delete any approval requests, only requestors can delete their approval requests. Figure 41. Approval Admin History

5. Advanced Topics

5.1. Data Access Control: Principles

This chapter describes the entity access control mechanism, which defines permissions for users and groups to access structures in Oracle 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 There are other permissions in Oracle 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 Section 6, 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 Page 205

5.1. Data Access Control: Principles

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 deletedhidden 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.

5.1.1. Explicit Permissions

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.

5.1.2. Permission Rules

When no explicit permission is set for the findget action on an entity, everyone can findget it. When no explicit permission is set for the savedelete action on an entity, only owner of the entity can savedelete 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: 1. Owner always has full control The owner can always process an operation over an owned entity, even if the permission is explicitly revoked. 2. 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. 3. 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. 4. 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. 5. 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. Page 206

5.1.2. Permission Rules