Privileges User Management Authorization

Managing Users 11-53 – When the Hierarchy Aware option is set to true, then the scope of the privilege is applicable to users who are direct members of the listed organization and the users who are members of any of the sub-organizations of these organizations. For example, if the organization is Development Center and it has USA Development Center and China Development Center as the suborganizations, then the privilege can be exercised against users in all of these organizations. ■ Assignee must be in the same organization: This flag limits the scope of the privilege for the assignee to only the assignees organization. For example, the organization list in the policy is USA, China, and Canada. If this flag is set and the assignees organization is USA, then the privilege can be exercised only in the USA organization. ■ Management chain of user: This flag limits the scope of the privilege for the assignee to only the assignees direct and indirect reports. For example: DR1, DR2, and DR3 are direct reports of M1. DR1_1, DR1_2, DR1_3, and DR1_4 are direct reports of DR1. DR2_1, DR2_2, and DR2_3 are direct reports of DR2. DR2_2_1 and DR2_2_2 are direct reports of DR2_2. Here, M1 can exercise the privilege on all of DR1, DR2, and DR3 and their direct and indirect reports if the Management Chain of User option is selected.

11.4.4 Authorization with Multiple Policies

If a user has multiple roles that have different authorization policies applicable in the same context, then the users access rights are the cumulative rights across those policies. The authorization check for the Search for Users permission returns a list of obligations. This is a list of obligations from each applicable authorization policy. These obligations from multiple policies are combined to get a unified search result. This section describes how obligations are handled for various user management operations. It contains the following topics: ■ Search Operation Authorization with Multiple Authorization Policies ■ Modify Operation Authorization with Multiple Authorization Policies

11.4.4.1 Search Operation Authorization with Multiple Authorization Policies

There can be the following types of obligations for the search operation: ■ List of organizations: The list of organizations can be for direct or indirect organization membership, which is controlled by the Hierarchy Aware data constraint. A special value here can be list of all organizations in Oracle Identity Manager. The logged in user can search only within this set of organizations. ■ Is in the same organization: This obligation means that the logged in user can search for users only in the users own organization. ■ Is in management hierarchy: This obligation means that the logged in user can search for any users in the users management hierarchy. ■ Viewable Attributes: This obligation contains the list of authorized viewable attributes. The search operation can be performed only against these attributes. 11-54 Oracle Fusion Middleware Users Guide for Oracle Identity Manager If there are multiple authorization policies that grant the search privilege to a user, then the search behavior is as follows: 1. The set of users who can be searched by the logged in user will be the union of set of users on which search privilege is provided by each of these policies. 2. The set of attributes returned as part of the search results is the union of sets of attributes on which View User Details privilege is granted by each of the these policies. This is described with the help of the following example: Policy1 returns the First Name, Last Name, and Middle Name attributes, and Policy2 returns the User Login, User Type, and OIM User Type attributes. When obligations from both the policies are enforced, the returned attribute list is First Name, Last Name, Middle Name, User Login, User Type, and OIM User Type for all users. The policy due to which the user is selected as part of the results is not checked. Therefore, do not configure attributes from the configuration service that might display confidential data in the search results. In an another example, suppose there are three authorization policies defined for the search operation. The following table lists the details of the sample authorization policies: In this example: ■ Org1 has Org1Child1 and Org1Child2 as child organizations. ■ Org1Child1 has Org1Child1_Child1 as the child organization. Policy Name Entity Name Permissions Data Constraints Assignment Policy1 User management Search Modify User Profile. Attributes include First Name, Last Name, and Middle Name View User Details. Attributes include Display Name, First Name, Last Name, and Middle Name Users that are members of the Org1 and Org2 organizations Hierarchy Aware include all Child Organizations = TRUE Role: Role1 Management Chain of User = FALSE Assignee must be a member of the Users Organization = TRUE Policy2 User management Search Modify User Profile. Attribute includes User Type View User Details. Attributes include User Login, User Type, and OIM User Type Users that are members of the Org3 organization Hierarchy Aware include all Child Organizations = FALSE Role: Role2 Management Chain of User = FALSE Assignee must be a member of the Users Organization = FALSE Policy3 User management Search Modify User Profile. Attribute includes Designation View User Details. Attributes include User Login, User Type, OIM User Type, and Designation All Users Role: Role2 Management Chain of User = TRUE Assignee must be a member of the Users Organization = FALSE Managing Users 11-55 ■ Org3 has Org3Child1 and Org3Child2 as child organizations. Consider the following scenarios: Scenario I: User1 has Role1 only and belongs to the Org1Child1 organization. The user can: ■ Search for users who are members of Org1Child1 organization. The search can be performed on the basis of First Name, Last Name, and Middle Name, and Display Name user attributes and also the search result can contain a subset of the set of these attributes. ■ Modify the First Name, Last Name, and Middle Name user attributes from the Org1Child1 organization. Scenario II: User2 has Role1 and Role2 and belongs to the Org2 organization. User2 has direct reports DR1 and DR2 belonging to the Org2 organization. The user can: ■ View the User Login, User Type, and OIM User Type user attributes from the Org3 organization because of Policy2. ■ Modify the User Type attribute from the Org3 organization because of Policy2. ■ View the First Name, Last Name, and Middle Name user attributes from the Org2 organization, because of Policy1. ■ Modify the First Name, Last Name, and Middle Name user attributes from the Org2 organization, because of Policy1. ■ View the User Login, User Type, OIM User Type, and Designation user attributes of all the users direct reports because of Policy3. ■ Modify the Designation attribute of all the users direct reports because of Policy3. If the user being tried to modify is DR1, then the list of modifiable attributes are First Name, Last Name, Middle Name because of Policy1, and Designation because of Policy3. The user cannot view, modify, and search users from child organizations of Org3, which are Org3Child1 and Org3Child2. Based on these scenarios, for the search operation, a union of the viewable attributes from all the three authorization policies are displayed to the user. In other words, the user is able to see User Login, User Type, OIM User Type, First Name, Last Name, Middle Name, Display Name, and Designation attributes in the search results irrespective of the authorization policy. Here, the Designation attribute is displayed not only for DR1 and DR2, who are direct reports of User2, but are displayed for all the users in the results.

11.4.4.2 Modify Operation Authorization with Multiple Authorization Policies

If the logged in user is allowed to modify a user profile as defined by multiple policies, then a union of the set of attributes from individual policies is used for performing the operation. Refer to Scenario II of the Search Operation Authorization with Multiple Authorization Policies on page 11-53 for the example related to the modify operation in case of multiple applicable authorization policies.