12 Managing Roles

You use roles to create and manage the records of a collection of users to whom you want to permit access to common functionality, such as access rights, roles, or permissions.

Roles can be independent of an organization, span multiple organizations, or contain users from a single organization.

Using roles, you can:

This chapter describes roles and functionalities related to roles in the following sections:

12.1 Role Membership Inheritance

Membership inheritance means that the members of the inheritor role inherit from the inherited role. For example:

Note:

The role that inherits membership is called the member-inheritor role. The role from which the member-inheritor role inherits membership is called the inherited-member role

  • Role B inherits memberships from Role A. Role B is the member-inheritor role to Role A.

  • Role C also inherits memberships from Role A. Role C is also a member-inheritor role of Role A.

In this example, all members of Role A are also implicit or indirect members of Role B and Role C, but members of Role B are not automatically members of Role A. In other words, Roles B and C are the member-inheritor roles of Role A, and Role A is the inherited-member role of Role B and Role C. A real example for this is that the Employee Role (Role B) inherits memberships from the Manager Role (Role A).

Role membership inheritance is described with the help of the following scenario:

  • The role of CEO is an inherited-member role of the Manager role, as a list of managers will include the CEO role.

  • The role Manager is an inherited-member role of the Employee role.

  • The role Software Architect is an inherited-member role of the Software Engineer role.

  • The role Software Engineer is an inherited-member role of the Employee role.

  • The Employee role has two inherited-member roles - the Manager role and the Software Engineer role.

Figure 12-1 shows the parent and child roles in this example, along with the membership inheritance:

Figure 12-1 Role Membership and Permission Inheritance

Description of Figure 12-1 follows
Description of "Figure 12-1 Role Membership and Permission Inheritance"

Each user in an inherited-member role automatically becomes a member in any of its member-inheritor roles. If that member-inheritor role is itself an inherited-member role, then the user is also added to its member-inheritor roles, and so on. This continues until there are no more member-inheritor roles in the inheritance chain. For example, a CEO is a manager and is automatically a member of the Manager role. Similarly, a manager is automatically an employee. This is why a member added to an inherited-member role gets inherited by its member-inheritor roles, and so on. This explains why the direct membership of the Employee role is empty, and considering membership inheritance, the Employee role has more members than all other roles.

A user can be a member of a role in one of the following ways:

  • The member has been inherited from the inherited-member role, which is called indirect membership.

  • The user is directly assigned to the role (by using membership rules), which is called direct membership.

An indirect member can be assigned as a direct member as well. If a user's direct membership in a role is revoked, the user is still a member of that role because of inheritance.

12.2 Role Permission Inheritance

Permission inheritance means that the permissions of the inheritor role inherit from the inherited role. For example:

  • Role B inherits permissions from Role A.

  • Role C also inherits permissions from Role A.

In this example, Role B and Role C are permissions-inheritor roles of Role A. In the Hierarchy tab, this relationship is denoted by "child" - Role B and Role C are the children of Role A. Similarly, Role A is the inherited-permissions role of Role B and Role C. In the Hierarchy tab, Role A is the "parent" of Role B and Role C.

A real example for this is that the Manager role inherits permissions from the Employee role.

Oracle Identity Self Service represents role permission inheritance through the following sections in the Hierarchy tab:

See Also:

"The Hierarchy Tab" for more information about the Hierarchy tab

  • Inherited From: Displays the parent roles from which the open role is inherited. The base role has the same permissions and privileges on the members as the inherited roles. Only inherited roles can be added or removed from the base role, but the base role cannot be added or removed from the inherited role.

  • Inherited By: Lists the child roles that are inherited by the open role. This is a read-only display of the roles. You can use the Open Role action to modify the relationship from the base role.

For example, you create three roles: role1, role2, and role3. Open role3 and assign role2 as the parent role. Similarly, open role2 and assign role1 as the parent role. When you open role3, the Inherited From section displays the role2 parent role, and role1 is displayed under role2. When you open role1, the Inherited By section displays the role2 child role, and role3 is displayed under role2.

Figure 12-1 illustrates that a permission on Employee is a permission that a Manager will have. Similarly, a permission a Manager will have is a permission a CEO will have. And this is why permissions inherit upwards. In addition, a parent role can inherit permissions from multiple child roles. For example, a CEO inherits the permissions of the Manager and Software Architect roles. Therefore, membership inheritance and permission inheritance go in different directions.

12.3 Role Entity Definition

Attributes are defined for the role entity in Oracle Identity Manager. These attributes are the same for all entities, such as user, organization, role, role hierarchy, and role membership. For a list of attributes defined for the entities, see "User Entity Definition".

Note:

You cannot add your own attributes for the role entity.

This section describes the default attribute definition of the following entities:

12.3.1 Role Entity

The Role.xml file contains the attribute definition for the role entity. You can add your own attributes to the role entity.

Attributes of an entity associated with a role can be made available through the Role API, when retrieving role details. This can be done without incurring the cost of an additional API call to retrieve the joined entity. Examples of these attributes are configured out-of-the-box in Role.xml, where the parameters with names beginning 'foreign_search_' collectively make available the attributes 'Role Category Name', 'Owner First Name', 'Owner Last Name', 'Owner Display Name', 'Owner Email', and 'Owner Login.

Note that the role entity definition contains the entity keys (Role Category Key and User Key), which enable these 'additional' attributes to be provided.

Table 12-1 lists the default attributes for the role entity.

Table 12-1 Default Attributes for the Role Entity

Attribute Name Category Type Data Type Properties LOV

Role Key

Basic

Single

Numeric

Required: Yes

System-Can-Default: Yes

System-Controlled: Yes

Encryption: Clear

User-Searchable: Yes

Bulk-Updatable: No

NA

Role Unique Name

Basic

Single

Text

Required: Yes

System-Can-Default: Yes

System-Controlled: Yes

Encryption: Clear

User- searchable: No

Bulk-Updatable: No

NA

Role Display Name

Basic

Single

Text (multi-language)

Required: Yes

System-Can-Default: Yes

System-Controlled: No

Encryption: Clear

User-Searchable: Yes

Bulk-Updatable: No

NA

Role Namespace

Basic

Single

Text

Required: Yes

System-Can-Default: Yes

System-Controlled: Yes

Encryption: Clear

User-Searchable: Yes

Bulk-Updatable: No

NA

Role Name

Basic

Single

Text (multi-language)

Required: Yes

System-Can-Default: No

System-Controlled: No

Encryption: Clear

User-Searchable: Yes

Bulk-Updatable: No

NA

Role Description

Basic

Single

Text (multi-language)

Required: Yes

System-Can-Default: No

System-Controlled: No

Encryption: Clear

User-Searchable: Yes

Bulk-Updatable: No

NA

LDAP GUID

LDAP

Single

Text

Required: Yes

System-Can-Default: No

System-Controlled: Yes

Encryption: Clear

User-Searchable: Yes

Bulk-Updatable: No

NA

LDAP DN

LDAP

Single

Text

Required: Yes

System-Can-Default: No

System-Controlled: Yes

Encryption: Clear

User-Searchable: Yes

Bulk-Updatable: No

NA

Role Category Key

Basic

Single

Reference to role category

Required: Yes

System-Can-Default: Yes

System-Controlled: No

Encryption: Clear

User-Searchable: Yes

Bulk-Updatable: Yes

NA

Role Owner Key

Basic

Single

Reference to Role Owner

Required: Yes

System-Can-Default: Yes

System-Controlled: No

Encryption: Clear

User-Searchable: Yes

Bulk-Updatable: Yes

NA

Role Email

Basic

Single

Text

Required: Yes

System-Can-Default: No

System-Controlled: No

Encryption: Clear

User-Searchable: Yes

Bulk-Updatable: No

NA


12.3.2 Role Category Entity

The RoleCategory.xml file contains the attribute definition for the role category entity. You cannot add your own attributes to the role category entity.

Table 12-2 lists the default attributes for the role category entity.

Table 12-2 Default Attributes for the Role Category Entity

Attribute Name Category Type Data Type Properties LOV

Role Category Key

Basic

Single

Text

Required: Yes

System-Can-Default: Yes

System-Controlled: Yes

Encryption: Clear

User-Searchable: Yes

Bulk-Updatable: No

NA

Role Category Name

Basic

Single

Text

Required: Yes

System-Can-Default: No

System-Controlled: No

Encryption: Clear

User-Searchable: Yes

Bulk-Updatable: No

NA

Role Category Description

Basic

Single

Text

Required: Yes

System-Can-Default: No

System-Controlled: No

Encryption: Clear

User-Searchable: Yes

Bulk-Updatable: No

NA


12.3.3 Role Grant Relationship

The RoleRoleRelationship.xml file contains the attribute definition for role grant relationship. You cannot add your own attributes for the role grant relationship.

Table 12-3 lists the default attributes for role grant relationship.

Table 12-3 Default Attributes for Role Grant Relationship

Attribute Name Category Type Data Type Properties LOV

UGP_KEY

Basic

Single

Reference to role

Required: Yes

System-Can-Default: No

System-Controlled: No

Encryption: Clear

User-Searchable: Yes

Bulk-Updatable: No

NA

USR_KEY

Basic

Single

Reference to user

Required: Yes

System-Can-Default: No

System-Controlled: No

Encryption: Clear

User-Searchable: Yes

Bulk-Updatable: No

NA


12.3.4 Role Parent Relationship

The RoleUserMembership.xml file contains the attribute definitions for role parent relationship. You cannot add your own attributes to the role parent relationship.

Table 12-4 lists the default attributes for the role parent relationship.

Table 12-4 Default Attributes for Role Parent Relationship

Attribute Name Category Type Data Type Properties LOV

UGP_KEY

Basic

Single

Reference to role

Required: Yes

System-Can-Default: No

System-Controlled: No

Encryption: Clear

User-Searchable: Yes

Bulk-Updatable: No

NA

GPG_UGP_KEY

Basic

Single

Reference to role

Required: Yes

System-Can-Default: No

System-Controlled: No

Encryption: Clear

User-Searchable: Yes

Bulk-Updatable: No

NA


Note:

UGP_KEY is a reference to the parent role. GPG_UGP_KEY is a reference to the child role.

12.3.5 Role Organization Relationship

A role organization relationship can be established by publishing the role to an organization. See "Publishing Entities to Organizations" for more information.

12.4 Default Roles

In Oracle Identity Manager, the following types of roles are available:

  • Enterprise roles: These are roles that users (depending on the permissions granted) can create in Oracle Identity Manager and request for by using the request catalog. See "Role Management Tasks" and "Request-Based Role Grants" for more information about creating and requesting roles.

  • Admin roles: These are predefined roles in Oracle Identity Manager that have a one-to-one mapping with the application roles defined in Oracle Entitlement Server. Admin roles are not visible to the end users. Therefore, admin roles cannot be requested. See "Admin Roles" for more information about admin roles.

Table 12-5 lists the default enterprise roles in Oracle Identity Manager. For a list of default admin roles, see "Admin Roles".

Note:

If you upgrade from Oracle Identity Manager 11g Release 1 (11.1.1), then the default roles of 11g Release 1 (11.1.1) will be available.

Table 12-5 Default Roles in Oracle Identity Manager

Role Description

ALL USERS

Members of this role have minimal permissions, including the ability to access the user's own user record. By default, each user belongs to the All Users role.

SYSTEM ADMINISTRATORS

This role is for internal use only, meaning it is for OIM users, and other users can only view it on UI. Members of this role have access to the UI to perform various tasks to manage attestation events.

Administrators

This role is for internal use only, meaning it is for OIM users, and other users can only view it on UI. It is the administrators role for SOA.

OPERATORS

This role is for internal use only, meaning it is for OIM users, and other users can only view it on UI. Members of this role have access to the pages related to organizations, users, and Task List. These users can perform a subset of functions on these pages.

SELF OPERATORS

This role is for internal use only, meaning it is for OIM users, and other users can only view it on UI. It contains one user, XELSELFREG, who is responsible for modifying the privileges that users have when performing self-registration actions within Oracle Identity Manager.

Note: Oracle Identity Manager recommends that you do not modify the permissions associated with the SELF OPERATORS user role. In addition, you should not assign any users to this role.


You can modify the permissions associated with the default roles. You can also create additional roles. However, you cannot assign/remove menu items to/from any roles.

12.5 Role Management Tasks

This section discusses the following topics:

Note:

A role, SELF OPERATORS, is added to Oracle Identity Manager by default. This role contains one user, XELSELFREG, who is responsible for modifying user permissions for performing self-registration in the Administration Console.

Oracle recommends that you do not modify the permissions associated with the SELF OPERATORS role and do not assign users to this role.

12.5.1 Creating Roles

When you first create a new role, the Role Details page shows the role name. You can add information to a role by using the Additional Detail menu as described in "Managing Roles".

To create a role:

  1. Log in to Identity Self Service.

  2. Under Administration, click Roles. The Search Roles page is displayed.

  3. From the Actions menu, select Create. Alternatively, click Create on the toolbar.

    The Create Role page is displayed.

  4. Enter values in the fields. Table 12-6 lists the fields in the Create Role page.

    Table 12-6 Fields in the Create Role Page

    Field Description

    Name

    The name of the role

    Display Name

    The role name as displayed in the UI

    Role E-mail

    The e-mail ID of the role

    Role Description

    The description for the role

    Role Category

    The category to which the role belongs

    If a role category is not specified in this field, then the role is created in the Default category. See "Creating and Managing Role Categories" for information about role categories.

    Owned By

    The owner of the role

    The role owner is a user who has permissions to view, modify, and delete the role without having to create custom authorization policies. For information about authorization policies for role management, see "Security Architecture" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager.


  5. Click Save. The role is created successfully. The role details page for the created role is displayed.

12.5.2 Managing Roles

You can find roles, add information to them, and perform other administrative functions for roles.

This section discusses the following topics:

12.5.2.1 Searching for Roles

To search for roles:

  1. In Identity Self Service, under Administration, click Roles. The Search Roles page is displayed.

  2. Select any one of the following:

    • All: On selecting this option, the search is performed with the AND condition. This means that the search operation is successful only when all the search criteria specified are matched.

    • Any: On selecting this option, the search is performed with the OR condition. This means that the search operation is successful when any search criterion specified is matched.

  3. In the searchable user attribute fields, such as Display Name, specify a value. You can include wildcard characters (*) in the attribute value.

    For some attributes, select the attribute value from the lookup. For example, to search all roles in the Default role category, select Default in the Role Category field.

  4. For each attribute value that you specify, select a search operator from the list. The following search operators are available:

    • Starts with

    • Ends with

    • Equals

    • Does not equal

    • Contains

    • Does not contain

    The search operator can be combined with wildcard characters to specify a search condition. The asterisk (*) character is used as a wildcard character. For example, you can specify the value of the Display Name attribute to be Jo* as the search criteria, and select Equals as the search operator. The roles with Display Name that begins with Jo are displayed.

  5. To add a searchable role attribute to the Search Roles page, click Add Fields, and select the attribute from the list of attributes.

    For example, if you want to search all roles in a role namespace, then you can add the Role Namespace attribute as a searchable field and specify a search condition.

    Note:

    You can configure the attributes that are searchable. The attributes available for search must be a subset of the attributes defined for the role entity that are marked with the Searchable = Yes property.

  6. Optionally click Reset to reset the search conditions that you specified. Typically, you perform this step to remove the specified search conditions and specify a new search condition.

  7. Click Search. The search results is displayed in a tabular format, as shown in Figure:

  8. If you want to hide columns in the search results table, then perform the following steps:

    1. Click View on the toolbar, select Columns, Manage Columns. The Manage Columns dialog box is displayed.

    2. From the Visible Columns list, select the columns that you want to hide.

    3. Click the left arrow icon to add the columns in the Hidden Columns list.

    4. Click OK. The selected columns are not displayed in the search results. A status message displays along the bottom of the search table to identify how many columns are currently hidden. Figure shows that two columns are hidden:

12.5.2.2 Viewing and Administering Roles

You can open the details of a role and edit the role attributes, modify the role inheritance and membership, and then publish roles to organization. To open the details of a role and modify it, perform one of the following:

  • In the Search Roles page, search and select the role that you want to open. From the Actions menu, select Open. Alternatively, click Open on the toolbar.

  • In the search results table of the Search Roles page, click the Display Name of the role.

The details of the role is displayed in a new page. The role display name is displayed at the top of the page. You can display the details of the role and modify role information in the following tabs of this page:

12.5.2.2.1 The Attributes Tab

The Attributes tab displays the role attributes. Except for the Role Namespace field (which is a read-only field), the rest of the fields in the Attributes tab are same as available in the Create Role page. The Role Namespace field displays the namespace to which the role is assigned. For information about the rest of the fields in the Attributes tab, see Table 12-6, "Fields in the Create Role Page".

To modify the role attributes, change the values in the fields, and click Apply.

12.5.2.2.2 The Hierarchy Tab

The Hierarchy tab displays the role hierarchy information in the following sections:

  • Inherits From: This section displays the parent roles from which the open role is inherited. The base role has the same permissions and privileges on the members as the inherited roles. Only inherited roles can be added or removed from the base role, but the base role cannot be added or removed from the inherited role.

  • Inherited By: This section lists the child roles that are inherited by the open role. This is a read-only display of the roles. You can use the Open Role action to modify the relationship from the base role.

In the Hierarchy tab. you can perform the following:

12.5.2.2.3 Adding a Parent Role to a Child Role

To add a parent role to a role:

  1. Open the role.

  2. Click the Hierarchy tab. In the Inherits From section, this tab lists the parent roles of the open from which the open role inherits permissions.

  3. Verify that Inherits From is active.

  4. From the Actions menu, select Add. Alternatively, click Add on the toolbar. The Search Roles dialog box is displayed.

  5. From the Search list, select a role attribute based on which you want to search for the role. Then, select an attribute by using the lookup icon. You can also include wildcard characters (*) in your search criterion. Then, click the search icon. A list of roles that matches your search criterion is displayed.

  6. Select one or more roles that you want to add as parent roles. Then, click Add Selected to move the selected roles to the Selected Roles list.

    Alternatively, you can click Add All to add all the roles in the Selected Roles list.

  7. Click Add. The selected roles are added as parent roles to the opened role and the role hierarchy is displayed in the Inherits From section of the Hierarchy tab.

  8. Select the inherited role that is added. A summary information of the role selected is displayed below the table.

    You can click the Display name of the inherited role to open the role details.

12.5.2.2.4 Removing a Parent Role from a Role

To remove a parent role from a role:

  1. In the Inherits From section of the Hierarchy tab, select the role that you want to remove.

  2. From the Actions menu, select Remove. Alternatively, click Remove on the toolbar. A message box is displayed asking for confirmation.

  3. Click OK. The inherited role is removed from the Inherits From section of the Hierarchy tab.

12.5.2.2.5 Opening a Parent/Child Role

You can open parent roles from the Inherits From section and child roles from the Inherited By section of the Hierarchy tab.

You can also open the roles that are linked parent and child roles (similar to grand parent roles and grand child roles) of the current opened role from the Inherited From and Inherited By sections of the Hierarchy tab respectively.

To open a parent role:

  1. In the Inherits From section of the Hierarchy tab, select the role that you want to open.

  2. From the Actions menu, select Open. Alternatively, click Open on the toolbar.

    A page with details about the inherited role is displayed. In this page, you can view and edit the role attributes, modify the role inheritance and membership, assign and remove membership rules, access policies, and permissions, and update permissions.

To open a child role:

  1. In the Inherits From or Inherited By section of the Hierarchy tab, select the role that you want to open.

  2. From the Actions menu, select Open. Alternatively, click Open on the toolbar. A page with details about the inherited role is displayed.

12.5.2.2.6 The Members Tab

The Members tab displays the members assigned to the open role. This information is displayed in the following sections:

  • Direct: This section displays the members that are directly assigned to the open role. It also displays all members that are assigned via membership rules.

  • Indirect: This section displays the members that are indirectly inherited by the role.

  • All: This section displays all the members, direct and indirect, assigned to the open role.

In the Members tab, you can perform the following:

12.5.2.2.7 Assigning Members to a Role

To assign members to a role:

  1. In the Direct section of the Members tab, click Assign on the toolbar. The Catalog page is displayed.

  2. In the Target Users section, click Add to select the members (users) to be assigned to the role. The Advanced Search for Target Users dialog box is displayed.

  3. Search and select one or more users that you want to add.

  4. Click Add Selected to add the selected users to the Selected Users list. Alternatively, click Add All to add all the users in the Selected Users list.

  5. Click Add. The selected users or beneficiaries are added to the Target Users section of the Request Cart Details page.

  6. In the Justification and Effective Date section, in the respective fields, specify a justification and effective date when the request will be active.

  7. In the Cart Items section, if required, select a cart item and click Details to display the details of the item.

  8. In the Details section, modify the request details, if required. To do so, set or modify values in the Details section, and then click Ready to Submit.

  9. After reviewing and modifying the details or each request in the cart, click Submit.

    The request is submitted for approval, and the Request Summary page is displayed with summary information, target user or beneficiary information, and request and approval details.

12.5.2.2.8 Revoking Members from a Role

To revoke members from a role:

  1. In any section of the Members tab, select the member that you want to revoke.

  2. Click Revoke on the toolbar. The Remove Roles page is displayed.

  3. In the Target Users section, verify the members to be revoked from the role.

  4. Enter values for the Justification and Effective Date fields.

  5. Click Submit. If you have the required authorization policies for revoking members from a role, then without any approval step, the users are removed from the role. If you do not have the required authorization policies, then the role will be revoked when an approver approves the request.

12.5.2.2.9 Adding, Modifying, and Deleting Membership Rules

In the Members tab, you can add, modify, or delete the user membership rules by using the expression builder. The expression builder lets you specify a condition based on which users are dynamically assigned to roles. You can specify simple to complex condition expressions as the user membership rule. When you modify a user membership rule, the existing user memberships are evaluated, and then the existing role memberships that are not valid are revoked and new role memberships are granted.

To add a user membership rule:

  1. In the Members tab, in the User Membership Rules section, click Add Rule. The Expression Builder is displayed.

  2. In the left pane, verify that <ADD> is selected. This is the placeholder to specify a user attribute for the condition.

  3. Under Select Operand Value, in the Attributes tab, select a user attribute, for example, Country.

  4. Click Add to add the attribute to the condition in the left pane.

  5. From the list of operators, select a comparator, such as = (equals), > (greater than), >= (greater than equal to), < (less than), => (less than equal to), and IN.

  6. Under Select Operand Value, in the Literals tab, specify a value in the Value field, such as United States of America.

    When a checkbox or lookup type UDF or default attribute is used in membership rule, then it must be treated as shown in the following example:

    ( ( ( Last Name = "Klein" ) AND ( First Name Contains "Robert" ) )
    OR ( ( User Login Starts with "rob" ) AND ( Common Name Ends with "ein" ) )
    OR ( ( Robert2UserUDF111DL != "Robert2UserUDF111DL" ) AND ( Robert2UserNumberDL >= 99999 )
    AND ( RobertUserDateDL =< 2013-12-31 ) AND ( Robert2UserchkboxDL = "1" )
    AND ( Robert2UserLookupDL IN ["RobertLookUpCode3","RobertLookUpCode9"] ) ) )
    

    Here:

    • Robert2UserchkboxDL is check box, which must be used in the rule as a string. Use "1" to check for True/yes/Selected/Checked, and use "0" to check for False/no/Unselected/unchecked.

    • Robert2UserLookupDL is lookup type. In the default userprofile, "Robert2LookUpMean3" will be displayed. But you must use its code value "Robert2LookUpCode3" in the expression.

    • For All type of Attributes, there is no way to check NULL or no value.

    Note:

    Checkbox fields are stored as strings in the backend. The data type for a checkbox field is a String and not Boolean. Therefore, all string operations will be displayed.

  7. Click Add to add the specified value to the condition expression. The expression now means that users belonging to United States of America will be dynamically assigned to the open role.

    Figure 12-2 shows the expression builder with the condition.

    Figure 12-2 The Expression Builder

    Description of Figure 12-2 follows
    Description of "Figure 12-2 The Expression Builder"

  8. If required, on the Preview Results tab, you can preview members to whom this rule will be applied.

  9. Click Save. The expression builder closes, and the rule you defined has been applied.

To modify a user membership rule:

  1. In the Members tab, in the User Membership Rules section, click Edit Rule. The expression builder is displayed.

  2. Specify a condition to dynamically assign members, as described in the steps for adding membership rule.

  3. If required, on the Preview Results tab, you can preview members to whom the modified rule will be applied.

  4. Click Save. The modified membership rule is applicable now.

To delete a user membership rule:

  1. In the Members tab, in the User Membership Rules section, click Delete Rule. A dialog box asking to confirm whether you want to delete the membership rule is displayed.

  2. Click Yes. The membership rule is deleted and no longer applicable.

12.5.2.2.10 The Organizations Tab

The Organizations tab allows you to assign and revoke organizations to and from the open role. By assigning an organization to the open role, you make the role available to the organization. This is called publishing the role entity to an organization.

All the organizations, to which the open role has been published, are displayed in the Organizations tab. For each organization, the include sub-orgs option is available for selection in the Hierarchy Aware column. Select this option if you want the open role to be available to the entire hierarchy of the organization. To make the open role available only to the organization and not its hierarchy, leave this option deselected.

In the Organizations tab, you can perform the following:

12.5.2.2.11 Publishing Roles to an Organization

To publish roles to an organization:

  1. In the Role details page, click the Organizations tab. This tab displays the organizations that are assigned to the open role.

  2. From the Actions menu, select Assign. Alternatively, click Assign on the toolbar. The Search Organizations dialog box is displayed.

  3. Search for the organizations you want to add. The organizations are displayed in the Organization Results section.

  4. Select the organizations that you want to add, and click Add Selected. The selected organizations are added to the Selected Organizations section.

  5. For each selected organization, the Hierarchy option is selected by default. If you want to publish the role to the suborganizations of the selected organization, then leave the Hierarchy option selected.

    To publish the role to the selected organization only, deselect the Hierarchy option.

  6. Click OK. The role is published to the selected organizations. In other words, the selected organizations are assigned to the role.

12.5.2.2.12 Revoking Organizations From a Role

To revoke an organization from a role:

  1. In the Organizations tab, select the organization that you want to revoke.

  2. From the Actions menu, select Revoke. Alternatively, click Revoke on the toolbar. A message is displayed asking for confirmation.

  3. Click Revoke. The organization is revoked from the role.

12.5.2.3 Viewing Access Policies

You can display all available access policies for this role. To view access policies assigned to the role:

In the Role details page, click Access Policy. The Access Policies page is displayed. This page displays the policy name and brief description of the policy.

12.5.2.4 Deleting Roles

To delete a role:

  1. In the Search Roles page, search for a role as described in "Searching for Roles".

  2. Select the role that you want to delete.

  3. From the Actions menu, select Delete. Alternatively, click Delete on the toolbar.

    A message is displayed asking for confirmation.

  4. Click Delete to confirm.

    Note:

    • You are not allowed to delete a role, which is the parent/child of some other role. To delete such a role, you must first remove the associated parent-child role relationships. When the role is no longer involved in any role relationships, it can be deleted.

    • You are not allowed to delete a role that has users associated with it.

12.5.3 Creating and Managing Role Categories

Role categories are a way of categorizing roles for the purpose of navigation and authorization. Role categories are internally stored in Oracle Identity Manager as an attribute of the role and is reconciled with the multivalued business category attribute in the LDAP identity store. If the value in LDAP is empty, then the role is assigned to the default role category. If the value in LDAP is an unrecognized value, then a role category (with the category name as the unrecognized value) is created, and then the role is assigned to this newly created role category. If the value in LDAP has multiple values, then the role reconciliation process does not reconcile the role and generates reconciliation errors in Oracle Identity Manager.

The default role categories in Oracle Identity Manager are:

  • OIM Roles: All the predefined roles in Oracle Identity Manager are assigned to this category. These are roles that exist in Oracle Identity Manager by default and are primarily used for managing permissions. There will not be any corresponding entity in LDAP store and catalog for these predefined roles.

  • Default: A newly created role must have a role category. Therefore, if a role category is not specified at the time of creating the role, then the role is assigned to this category by default.

    Note:

    The default role categories cannot be localized.

This section describes the following topics:

12.5.3.1 Creating a Role Category

To create a role category:

  1. In Identity Self Service, under Administration, click Role Categories. The Search Role Categories page is displayed.

  2. From the Actions menu, select Create. Alternatively, click Create on the toolbar. The Create Role Category page is displayed.

  3. In the Role Category box, enter the name of the role category.

  4. In the Role Category Description box, enter a description for the role category. This step is optional.

  5. Click Save. The role category is created, and the role category details page is displayed. The page consists of the Attributes and Roles tabs.

    The Attributes tab displays the attributes of the role category. You can edit the fields in this tab to edit the role category.

    The Roles tab displays the list of roles belonging to the role category.

12.5.3.2 Searching Role Categories

To search for role categories:

  1. Under Administration, click Role Categories. The Search Role Categories page is displayed.

  2. In the Role Category field, specify a value. You can include wildcard characters (*) in the attribute value.

  3. For the attribute value that you specify, select a search operator from the list. The following search operators are available:

    • Starts with

    • Ends with

    • Equals

    • Does not equal

    • Contains

    • Does not contain

    The search operator can be combined with wildcard characters to specify a search condition. The asterisk (*) character is used as a wildcard character. For example, you can specify the value to be D* as the search criteria, and select Equals as the search operator. The role categories that begins with D are displayed.

  4. To add a searchable attribute to the Role Categories, click Add Fields, and select the attribute from the list of attributes.

  5. Optionally click Reset to reset the search conditions that you specified. Typically, you perform this step to remove the specified search conditions and specify a new search condition.

  6. Click Search. The search results is displayed in a tabular format.

12.5.3.3 Modifying a Role Category

To modify a role category:

  1. In the Search Role Categories page, search and select the role category you want to modify.

  2. From the Actions menu, select Open. Alternatively, click Open on the toolbar. A page with details about the role category is displayed.

  3. The Attributes tab is open by default. Edit the fields in this tab to modify basic category information such as name and description. When finished, click Apply.

  4. Click the Roles tab. In this tab, you can view all roles that are assigned to this category.

12.5.3.4 Deleting a Role Category

To delete a role category:

  1. In the Search Role Categories page, search and select the role category you want to delete.

  2. From the Actions menu, select Delete. Alternatively, click Delete on the toolbar.

    If the role category detail page is open, then click Delete on the toolbar.

    A message box is displayed asking for confirmation.

  3. Click Delete. The role category is deleted.

Note:

You cannot delete a role category that has roles associated with it.

12.6 Request-Based Role Grants

Oracle Identity Manager generates a request when a role grant is performed. This request is subject to approval, and therefore, the role grant takes place only when the role grant request has been approved.

After a role grant request is generated, the request ID is displayed. This is for tracking the request in Identity Self Service or Oracle Identity System Administration.

Role grant requests have the following details:

  • Request ID: Automatically generated

  • Request Type: Type of request

  • Request Status: Assigned

  • Date Requested: Current timestamp

  • Effective Date: Current timestamp

  • Requester: Null

  • Beneficiary: Null

  • Justification: Null