Oracle® Fusion Middleware User's Guide for Oracle Identity Manager 11g Release 1 (11.1.1) Part Number E14316-07 |
|
|
PDF · Mobi · ePub |
As an administrator, 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:
View the menu items that the users can access through Oracle Identity Manager Administration Web interface.
Assign users to roles.
Assign a role to a parent role
Designate status to the users so that they can specify defined responses for process tasks.
Modify permissions on data objects.
Designate provisioning policies for a role. These policies determine if a resource object is to be provisioned to or requested for a member of the role.
Assign or remove membership rules to or from the role. These rules determine which users can be assigned or removed as direct membership to or from the role.
This chapter describes roles and functionalities related to roles in the following sections:
Membership inheritance means that the members of the inheritor role inherit from the inherited role. For example:
Note:
The child role that inherits membership from its parent role is called the inheritor role. The parent role from which the inheritor role inherits membership is called the inherited role.Role B inherits memberships from Role A. Role B is parent role to Role A.
Role C also inherits memberships from Role A. Role C is also parent 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, Role B and Role C are the parents of Role A. Similarly, Role A is the child 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 CEO is a parent role of the Manager role.
The role Manager is a parent role of the Employee role.
The role Software Architect is a parent role of the Software Engineer role.
The role Software Engineer is a parent role of the Employee role.
The Employee role has two parent roles - the Manager role and the SoftwareEngineer 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
Each user in a parent role automatically becomes a member in any of its child roles. If that child role is itself a parent, then the user is also added to its child roles, and so on. This continues until there are no more child roles. 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 a parent role gets inherited by its children 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.
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 the children of Role A. Similarly, Role A is also the parent of Role B and Role C.
A real example for this is that the Manager role inherits permissions from the Employee role.
The Administrative and User Console represents role permission inheritance through the following sections in the Hierarchy tab:
See Also:
"The Hierarchy Tab" for more information about the Hierarchy tabInherited 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.
A user can be a member of a role in one of the following ways:
The member has been inherited from the parent role, which is called indirect membership.
The user is directly assigned to the role, which is called direct membership.
The user can be assigned directly via request in the role details page by setting the XL.RM_REQUEST_ENABLED and XL.RM_ROLE_ASSIGN_TEMPLATE system properties, which is also called direct membership. See "Administering System Properties" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for information about system properties.
An indirect member can be assigned as direct member. If the direct membership for a user is removed, then all membership for that role does not change because that user is still a member of that because of inheritance.
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.
Attributes are defined for the role entity in Oracle Identity Manager. For each attribute for a role entity, the following properties are defined in Oracle Identity Manager:
Note:
You cannot add your own attributes for the role entity.Attribute Name: The name of the attribute.
Category: All entity attributes are classified into a category. This categorization is used to organize the data in the UI. It is also used for delegated authorization.
See Also:
"Managing Authorization for Roles" for information about authorization for role management
"Creating and Managing Role Categories" for information about role categories
Type: Indicates whether the attribute is a single-valued attribute or not.
Data Type: Indicates the type of data in the attribute. Supported types are: Text, Numeric, Date, which indicates both date and time), Boolean, and Reference, which is a pointer to another entity.
Properties: For each attribute, a bunch of properties can be defined. The properties are:
Required: Determines whether or not every entity in the repository must have a non-NULL value for this attribute
System Controlled: Determines if the value can be set and edited by Oracle Identity Manager exclusively, which is read-only for the user
System Can Default: Determines whether or not the value can be set by Oracle Identity Manager to a default if no value is provided
Encrypted: Determines if the value is stored in the repository as reversible encrypted or clear
Searchable: Determines if the values can be used in searches or not
Support Bulk Update: Determines if the field can be modified as part of a bulk modification of multiple role. Fields that are expected to be unique to roles, such as role names, must not support bulk update. For fields that are System Controled=Yes, this property can never be set to Yes.
Display: Determines how the field is displayed in the UI. It can have any one of the following values:
Clear: Show the value as clear text
Masked: Mask the value in any UI
Partial Mask: Mask part of the value in the UI (de-scoped to 9.3)
Dependency: The value of some attributes can depend on the value of other attributes. This property lists the other attributes that this attribute depends on. If any of those attributes are to be changed, then the autogenerate or prepopulate adapters for this attribute must be run.
LOV: For some attributes, the value the field can take may be constrained to a list of values. You can modify the available values in the LOV that are marked configurable. If the LOV is not marked configurable, then you cannot add your own values or modify the LOV.
This section describes the default attribute definition of the following entities:
Table 12-1 lists the default attributes for the role entity. You can add your own attributes to the role entity.
Table 12-1 Default Attributes for the Role Entity
Attribute Name | Category | Type | Data Type | Properties | LOV |
---|---|---|---|---|---|
Key |
Basic |
Single |
Numeric |
Required: Yes System Can Default: Yes System Controlled: Yes Encrypted: Clear Searchable: Yes Unique: Yes Support Bulk Update: No |
NA |
Role Unique Name |
Basic |
Single |
Text |
Required: Yes System Can Default: Yes System Controlled: Yes Encrypted: Clear Searchable: No Unique: Yes Support Bulk Update: No |
NA |
Role Display Name |
Basic |
Single |
Text (multi-language) |
Required: Yes System Can Default: Yes System Controlled: No Encrypted: Clear Searchable: Yes Unique: No Support Bulk Update: No |
NA |
Role Namespace |
Basic |
Single |
Text |
Required: Yes System Can Default: Yes System Controlled: Yes Encrypted: Clear Searchable: Yes Unique: No Support Bulk Update: No |
NA |
Role Name |
Basic |
Single |
Text (multi-language) |
Required: Yes System Can Default: No System Controlled: No Encrypted: Clear Searchable: Yes Unique: No Support Bulk Update: No |
NA |
Role Description |
Basic |
Single |
Text (multi-language) |
Required: Yes System Can Default: No System Controlled: No Encrypted: Clear Searchable: Yes Unique: No Support Bulk Update: No |
NA |
LDAP GUID |
LDAP |
Single |
Text |
Required: Yes System Can Default: No System Controlled: Yes Encrypted: Clear Searchable: Yes Unique: Yes Support Bulk Update: No |
NA |
LDAP DN |
LDAP |
Single |
Text |
Required: Yes System Can Default: No System Controlled: Yes Encrypted: Clear Searchable: Yes Unique: Yes Support Bulk Update: No |
NA |
Role Category Key |
Basic |
Single |
Reference to role category |
Required: Yes System Can Default: Yes System Controlled: No Encrypted: Clear Searchable: Yes Unique: No Support Bulk Update: Yes |
NA |
Role Owner Key |
Basic |
Single |
Reference to Role Owner |
Required: Yes System Can Default: Yes System Controlled: No Encrypted: Clear Searchable: Yes Unique: No Support Bulk Update: Yes |
NA |
Role Email |
Basic |
Single |
Text |
Required: Yes System Can Default: No System Controlled: No Encrypted: Clear Searchable: Yes Unique: No Support Bulk Update: No |
NA |
Table 12-2 lists the default attributes for the role category entity. You cannot add your own attributes to 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 Encrypted: Clear Searchable: Yes Unique: Yes Support Bulk Update: No |
NA |
Role Category Name |
Basic |
Single |
Text |
Required: Yes System Can Default: No System Controlled: No Encrypted: Clear Searchable: Yes Unique: No Support Bulk Update: No |
NA |
Role Category Description |
Basic |
Single |
Text |
Required: Yes System Can Default: No System Controlled: No Encrypted: Clear Searchable: Yes Unique: No Support Bulk Update: No |
NA |
Table 12-3 lists the default attributes for role grant relationship. You cannot add your own attributes for the 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 Encrypted: Clear Searchable: Yes Unique: No Support Bulk Update: No |
NA |
USR_KEY |
Basic |
Single |
Reference to user |
Required: Yes System Can Default: No System Controlled: No Encrypted: Clear Searchable: Yes Unique: No Support Bulk Update: No |
NA |
Table 12-4 lists the default attributes for the role parent relationship. You cannot add your own attributes to 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 Encrypted: Clear Searchable: Yes Unique: No Support Bulk Update: No |
NA |
GPP_UGP_KEY |
Basic |
Single |
Reference to role |
Required: Yes System Can Default: No System Controlled: No Encrypted: Clear Searchable: Yes Unique: No Support Bulk Update: No |
NA |
Table 12-5 lists the default roles in Oracle Identity Manager:
Table 12-5 Default Roles in Oracle Identity Manager
Role | Description |
---|---|
USER CONFIGURATION ADMINISTRATORS |
Members of this role have access to the UI to perform various tasks to create and manage entity attributes for user management. |
SYSTEM CONFIGURATION 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 related to system configuration, such as system properties, scheduled jobs, and notification templates. |
SYSTEM ADMINISTRATORS |
Members of this role have full permission to create, edit, and delete records in Oracle Identity Manager, except for system records. These users can control the permissions of other users, change the status of process tasks even when the task is not assigned to them, and administer the system from the highest level. |
USER NAME ADMINISTRATORS |
This role is for internal use only, meaning it is for OIM users and other users can only view it on UI. |
SPML_App_Role |
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 submit requests via the SPML interfaces. |
SOD ADMINISTRATORS |
Members of this role can claim a SoD check task and approve it. Default approval tasks are assigned to this role. |
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. |
SCHEDULER ADMINISTRATORS |
This role is for internal use only, meaning it is for OIM users and other users can only view it on UI. The user with this role can perform all scheduler jobs administration. |
ROLE ADMINISTRATORS |
Members of this role have access to the UI to administer and manage roles in Oracle Identity Manager. |
RESOURCE 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 resources. |
REQUEST TEMPLATE ADMINISTRATORS |
The user with this role can perform all request template administration. |
REQUEST ADMINISTRATORS |
Members of this role have access to the UI to perform various tasks to create and manage requests. |
REPORT 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 reports in BI Publisher. |
RECONCILIATION ADMINISTRATORS |
The user with this role can perform reconciliation administration. |
PLUGIN ADMINISTRATORS |
This role is for internal use only, meaning it is for OIM users and other users can only view it on UI. Member of this role have permissions to register and unregister plugins to Oracle Identity Manager. |
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. |
NOTIFICATION TEMPLATE 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 create and manage notification templates. |
IT RESOURCE 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 create and manage IT resources. |
IDENTITY USER ADMINISTRATORS |
Members of this role have access to the UI to perform various tasks to create and manage users in Oracle Identity Manager. |
IDENTITY ORGANIZATION ADMINISTRATORS |
Members of this role have access to the UI to perform various tasks to create and manage organizations in Oracle Identity Manager. |
GENERIC CONNECTOR 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 configure generic connectors. |
DEPLOYMENT MANAGER 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 Deployment Manager to import and export deployment configurations from an Oracle Identity Manager deployment to another. |
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. |
ATTESTATION EVENT 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. |
ATTESTATION CONFIGURATION 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 configure attestation. |
APPROVAL POLICY 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 create and manage approval policies. |
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. |
ACCESS POLICY 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 can access the UI to perform various tasks to manage access policies. |
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.
This section discusses the following topics:
Note:
A user cannot be removed from the All Users role.
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.
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:
Login to Oracle Identity Administration.
In the Welcome page, under Roles, click Create New Role.
Alternatively, in the Browse tab of the left pane, expand Roles, and from the Actions menu, select Create Role. Otherwise, click the Create Role icon on the toolbar.
The Create Role page is displayed.
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 |
---|---|
Role Name |
The name of the role |
Display Name |
The role name as displayed in the UI |
|
The e-mail ID of the 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. See "Managing Authorization for Roles" for information about authorization policies for role management. |
Note that Manage Localizations is displayed with the Display Name fields because these are multi-language fields. This means that you can enter and save attribute values in more than one language.
Click Save. The role is created successfully and role name, role namespace, LDAP Attributes such as LDAP GUID and LDAP DN are displayed in a new page.
You can find roles, add information to them, and perform other administrative functions for roles.
This section discusses the following topics:
You can browse the roles that exist in Oracle Identity Manager in the Roles tab. To browse roles:
In the left pane of Oracle Identity Administration, click the Browse tab.
Expand OIM Roles. The role categories are displayed. For more information about role categories, see "Creating and Managing Role Categories".
In the Browse tab, you can perform various tasks related to roles and role categories. For details, see "Viewing and Administering Roles".
Oracle Identity Management Administration allows you to perform the following types of search operations for roles:
To perform a simple search for roles:
In the left pane of Oracle Identity Administration, under Search, select Roles.
Specify a search criterion in the field next to the list. You can include wildcard characters (*) in your search criterion. For performance reasons, initial (prefix) wildcards will be removed. However, a trailing (prefix) wildcard will be added to all searches.
Note:
"*" is the only wildcard search allowed in Oracle Identity Management Administration.Click the search icon to the right of the field. A list of roles that match the search criterion is displayed in the Search Results tab.
In the Search Results tab, you can edit and delete roles. For details, see "Viewing and Administering Roles" and "Deleting Roles".
To perform an advanced search for roles:
In the Welcome page, under Roles, click Advanced Search - Roles.
Alternatively, in the Browse tab for roles in the left pane, you can click the Advanced Search: Roles icon on the toolbar.
The Advanced Search: Roles page is displayed.
Select any one of the following options:
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.
In the Name field, enter the role name that you want to search. You can use wildcard characters in your search criteria. Select a search comparator in the list adjacent to the Name field. The default search comparator is "Begins With". The comparator "Equals" is available in the pulldown list as an alternative.
Similarly, enter search criteria in all the other fields. You can add fields to the Advanced Search: Roles page. To do so, click Add Fields, and then select the field name from the list.
Click Search. The roles that match your search criteria are displayed in the search results table.
Note:
Clicking Search without any value returns all roles.Click View and select Columns to view additional columns in the search results.
Click View and Reorder Columns to reorder the columns in the search results.
From the search results in the Advanced Search: Roles page, you can create new roles, edit roles, and delete roles. For details, see "Creating Roles", "Viewing and Administering Roles", and "Deleting Roles".
Search for a role as described in "Searching for Roles". Alternatively, you can click the Browse tab for roles in the left pane.
Select the role that you want to delete.
From the Actions list, select Delete.
Alternatively, you can click the delete icon on the toolbar. A message box is displayed asking for confirmation.
Click OK 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. Once the role is no longer involved in any role relationships, it can be deleted.You can open the details of a role and edit the role attributes, and modify the role inheritance and membership. To open the details of a role and modify it, perform one of the following:
In the role browse tree, select the role that you want to open. From the Actions menu, select Open. Alternatively, you can click the Open Role or Category Detail icon on the toolbar.
In the Search Results tab of the left pane, select the role that you want to open. From the Actions menu, select Open. Alternatively, you can click the Open Role Detail icon on the toolbar.
In the Advanced Search: Roles page, select the role that you want to open. From the Actions menu, select Open. Alternatively, you can click Open Role on the toolbar.
The details of the role is displayed in a 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:
The Attributes tab displays the role attributes in the following sections:
Basic Role Information: This section displays the basic attributes of the role such as role name, role namespace, display name, e-mail, and description.
Other Information: This section displays the information about the category to which the role belongs and the owner of the role.
Custom Attributes: This section displays information about the user-defined fields (UDFs).
LDAP Attributes: This section displays information about LDAP GUID and LDAP DN if Oracle Identity Manager is integrated with LDAP. These are read-only attributes.
The fields in the Attributes tab are same as available in the Create Role page. For information about all the fields in the Attributes tab, see Table 12-6, "Fields in the Create Role Page".
The Hierarchy tab displays the role hierarchy information in the following sections:
Inherited 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:
To add a parent role to a role:
Open the role.
Click the Hierarchy tab.
Verify that the Inherited From section is active.
From the Actions menu, select Add Parent Role. Alternatively, click Add Parent Role on the toolbar. The Add Inherited Role to: dialog box is displayed.
From the Search Roles list, select a role category whose roles you want to search.
In the search field, specify a search criterion. You can include wildcard characters (*) in your search criterion. Then, click the search icon. A list of roles that matches your search criterion and selected role category is displayed in the Available Roles list.
Note:
"*" is the only wildcard search allowed in Oracle Identity Management Administration.From the Available Roles list, select one or more roles that you want to add as parent roles. Then, click Move or Move All to move the selected roles to the Roles to Add list.
Click Save. The selected roles are added as parent roles to the opened role and the role hierarchy is displayed in the Inherited From section of the Hierarchy tab.
Select the inherited role that is added. A Summary Information of the role selected is displayed below the table.
To remove a parent role from a role:
In the Inherited From section of the Hierarchy tab, select the role that you want to remove.
From the Actions menu, select Remove Parent Role. Alternatively, click Remove Parent Role on the toolbar. A message box is displayed asking for confirmation.
Click OK. The inherited role is removed from the Inherited From section of the Hierarchy tab.
You can open parent roles from the "Inherited 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 (like grand parents and grand child roles) of the current opened role with the "Open Role" link in "Inherited From" and "Inherited By" section of the Hierarchy tab respectively.
To open a parent role:
In the Inherited From section of the Hierarchy tab, select the role that you want to open.
From the Actions menu, select Open (Open Role Detail). Alternatively, click Open (Open Role Detail) on the toolbar. A page with details about the inherited role is displayed. In this page, you can view and edit the role attributes, and modify the role inheritance and membership, assign and remove membership rules, access policies and permissions, update permissions and also to view the menu items assigned.
To open a child role:
In the Inherited From or Inherited By section of the Hierarchy tab, select the role that you want to open.
From the Actions menu, select Open (Open Role Detail). Alternatively, click Open (Open Role Detail) on the toolbar. A page with details about the inherited role is displayed.
The Members tab displays the members assigned to the open role. This information is displayed in the following sections:
All Members: This section displays all the members, direct and indirect, assigned to the open role.
Direct Members: 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 Members: This section displays the members that are indirectly inherited by the role.
In the Members tab, you can perform the following:
To assign members to a role:
In any section of the Members tab, from the Actions menu, select Assign (Assign Users). Alternatively, click Assign User to on the toolbar. The Assign User to: dialog box is displayed.
Search for users by specifying a search criterion in the Search Users field and clicking the search icon. The list of users that matches your search criterion is displayed in the Available list.
Note:
An indirect member can be assigned as a direct member.Select one or more users that you want to assign to the open role. Then, click Move or Move All to move the selected users to the Selected list.
Click Save. If the XL.RM_REQUEST_ENABLED and XL.RM_ROLE_ASSIGN_TEMPLATE system properties are set, then after clicking Save, a confirmation message is displayed in the role details page along with the request ID. Otherwise, only a confirmation message is displayed.
If a request is created, then the users are displayed as members in the Direct Members section only after the request is approved. Otherwise, the users are displayed as members immediately in the Direct Members section. Also, note that the users are displayed in the All Members section.
Tip:
If the member users are not displayed in the Members tab immediately after they are added, then refresh the view.
If users are created or updated to match membership rules criteria, then they are assigned directly to this role and the table must be refreshed to view those members in both sections, All Members and Direct Members.
To revoke members from a role:
In any section of the Members tab, select the member that you want to revoke.
From the Actions menu, select Revoke (Revoke Members). Alternatively, click Revoke Members from: on the toolbar. The Revoke User from: dialog box is displayed.
Search for members by specifying a search criterion in the Search Users field and clicking the search icon. The list of members that matches your search criterion is displayed in the Available list.
Note:
Only direct members can be revoked except for the members that are assigned via membership rules.Select one or more members that you want to revoke from the open role. Then, click Move or Move All to move the selected members to the Selected list.
Click Save. A confirmation message is displayed on the role details page.
The members that you have revoked are removed from the list of members in the Members tab.
To open the member user details of the open role:
In any section of the Members tab, select the member whose details you want to open.
From the Actions menu, select Open (Open Member Detail). Alternatively, click Open User on the toolbar. The user details page for the member is displayed that allows you to view and modify the member details.
You can display all menu items that are permitted for the role. In11g Release 1 (11.1.1), new menu items cannot be assigned to any role. By default, menu items are already assigned to some default roles in Oracle Identity Manager.
Note:
The existing menu items cannot be revoked.To display the menu items for a role:
In the browse tree for roles on the left pane, select a role for which you want to display the permitted menu items.
From the Actions menu, select Menu Items. The Role Details >> Menu Items page is displayed with a list of menu items permitted for the selected role.
You can display all available access policies for this role and assign and revoke access policies for the role.
To assign access policies to a role:
In the browse tree for roles on the left pane, select the role for which you want to assign access policy.
From the Actions menu or Role Details page select Access Policies. The Access Policies page is displayed.
To assign a new access policy, click Assign Policy. The Assign Access Policies page is displayed.
This page displays the policy name and brief description of the policy.
Select the Assign option for the access policies that you want to assign to this role, and then click Assign. The Confirmation page is displayed.
To assign the access policy, click Confirm Assign. The Access Policies page is displayed.
To remove this access policy, select the Delete option for the access policies that you want to remove from this role, and then click Delete. In the confirmation page, Click Confirm Delete to remove access policies from this role
You can display all available membership rules for this role, assign a new membership rule for the role, and remove membership rules.
To work with membership rules:
In the browse tree for roles, select the role for which you want to assign or revoke membership rules.
From the Actions menu, select Membership Rules. The Membership Rules page is displayed.
To assign a new membership rule, click Assign Rules. The Assign Membership Rules page is displayed. This page displays the name of the membership rule.
Select the Assign option for the membership rules that you want to assign to this role, and then click Assign. The Confirmation page is displayed.
To assign the membership rule, click Confirm Assign. Otherwise, click Cancel. The Membership Rules page is displayed.
To revoke this membership rule, select the Delete option for the membership rule that you want to remove from this role, and then click Delete. In the confirmation page click Conform Delete to remove the rules from this role.
Most permissions in Oracle Identity Manager concern data objects. You can define data objects as an internal object representation of tables in Oracle Identity Manager data model. In this model, the business logic is executed and responsible for inserting, updating, and deleting data from the data store. Permissions for these actions are defined at a role level. Depending on the table or data objects, these permissions can be categorized into the following:
Data objects for which explicit insert, update, or delete permission is required are the ones for which you must specify the insert, update, or delete permission by using Permissions from the Role Details page in Oracle Identity Manager Administrative and User Console to create, modify, and delete entities of these data objects.
Consider the following example: A user belongs to multiple roles and a data object is assigned to both of these roles. Suppose you want to delete an entity of this data object type. To be able to do so, you must ensure that both roles have update permission on the data object.
Table 12-7 lists the data objects listed in this category and the entities of these data objects.
Table 12-7 Data Objects Requiring Explicit Insert/Update/Delete Permissions
Data Object Type | Entities |
---|---|
com.thortech.xl.dataobj.tcACS |
Organization.Lnk_Act_Svr |
com.thortech.xl.dataobj.tcADL |
Adapter Factory Logic/SetVariable tasks |
com.thortech.xl.dataobj.tcADM |
Adapter Factory Input/output parameters |
com.thortech.xl.dataobj.tcADP |
Adapter Definitions |
com.thortech.xl.dataobj.tcADS |
Adapter Factory Stored Procedure tasks |
com.thortech.xl.dataobj.tcADT |
Adapter Tasks |
com.thortech.xl.dataobj.tcADU |
Adapter Factory WebServices tasks |
com.thortech.xl.dataobj.tcADV |
Adapter Factory Variables |
com.thortech.xl.dataobj.tcAPA |
Attestation Process Administrators |
com.thortech.xl.dataobj.tcARS |
Adapter Statuses |
com.thortech.xl.dataobj.tcATP |
Adapter Factory Parameter Task Table |
com.thortech.xl.dataobj.tcDAV |
Data Object Adapter Variable |
com.thortech.xl.dataobj.tcDVT |
Event handlers associated with data objects |
com.thortech.xl.dataobj.tcEMD |
Email Definitions |
com.thortech.xl.dataobj.tcERR |
Error Message Definitions |
com.thortech.xl.dataobj.tcEVT |
Event Handlers |
com.thortech.xl.dataobj.tcGPY |
role Properties |
com.thortech.xl.dataobj.tcLKU |
Lookup Definitions |
com.thortech.xl.dataobj.tcLKV |
Lookup values for a lookup |
com.thortech.xl.dataobj.tcOBA |
Resource object authorizers |
com.thortech.xl.dataobj.tcODF |
Object To Process Data Flow |
com.thortech.xl.dataobj.tcODV |
Resource object Events |
com.thortech.xl.dataobj.tcOOD |
Resource Objects Organization Object Dependencies |
com.thortech.xl.dataobj.tcOUD |
Resource Objects User Object Dependencies |
com.thortech.xl.dataobj.tcPDF |
Process Integration Data Flow Mappings |
com.thortech.xl.dataobj.tcPKH |
Package Hierarchy |
com.thortech.xl.dataobj.tcPOC |
Access Policies Child Table Data |
com.thortech.xl.dataobj.tcPOF |
Policy parent data |
com.thortech.xl.dataobj.tcPOG |
roles defined on access policy |
com.thortech.xl.dataobj.tcPOL |
Access policy definition |
com.thortech.xl.dataobj.tcPOP |
Assigned Objects on access policies |
com.thortech.xl.dataobj.tcPRF |
Process Reconciliation Field Mappings |
com.thortech.xl.dataobj.tcPTY |
System Configuration |
com.thortech.xl.dataobj.tcPWP |
Policy Process Targets |
com.thortech.xl.dataobj.tcPWR |
Password Policies |
com.thortech.xl.dataobj.tcPWT |
Policy User Targets |
com.thortech.xl.dataobj.tcRAV |
Prepopulate Adapter Mappings |
com.thortech.xl.dataobj.tcRCA |
Reconciliation Matched Organizations |
com.thortech.xl.dataobj.tcRCH |
Reconciliation Event Action History |
com.thortech.xl.dataobj.tcRCP |
Reconciliation Event Processes Matched |
com.thortech.xl.dataobj.tcRCU |
Reconciliation Event Users Matched |
com.thortech.xl.dataobj.tcRCX |
Reconciliation Exceptions |
com.thortech.xl.dataobj.tcRES |
Adapter Factory Resources |
com.thortech.xl.dataobj.tcRGP |
Role Membership Rules |
com.thortech.xl.dataobj.tcRML |
Task Assignment Rules |
com.thortech.xl.dataobj.tcRPG |
Reports on roles |
com.thortech.xl.dataobj.tcRUL |
Rules |
com.thortech.xl.dataobj.tcRUE |
Rule Element |
com.thortech.xl.dataobj.tcSDC |
User defined columns on system user-defined forms |
com.thortech.xl.dataobj.tcSDH |
Parent child hierarchy of user defined forms |
com.thortech.xl.dataobj.tcSDL |
Form Definition Version Label |
com.thortech.xl.dataobj.tcSDP |
Form Definition Properties |
com.thortech.xl.dataobj.tcSPD |
IT Resources Type Parameter Definition |
com.thortech.xl.dataobj.tcSRE |
Association between user defined columns and pre-populate adapters |
com.thortech.xl.dataobj.tcSRS |
IT Resource Link |
com.thortech.xl.dataobj.tcSUG |
IT Resources Administrators |
com.thortech.xl.dataobj.tcSVD |
IT Resources Type Definition |
com.thortech.xl.dataobj.tcTDV |
Process Event Handlers |
com.thortech.xl.dataobj.tcTLG |
System Log |
com.thortech.xl.dataobj.tcTSA |
Schedule Task Attributes |
com.thortech.xl.dataobj.tcTSK |
Scheduled Tasks |
com.thortech.xl.dataobj.tcUHD |
Users Objects History Details |
com.thortech.xl.dataobj.tcUPL |
User Defined Field Lookups |
com.thortech.xl.dataobj.tcUPT |
User Defined Field Values |
com.thortech.xl.dataobj.tcUPY |
System Configuration Users |
com.thortech.xl.dataobj.tcWIN |
Form Information |
Data objects for which explicit permission is not required are the ones for which permissions do not need to be defined because either there are no permissions enforced or they simply follow parent data object permissions. Data objects that use parent data object permissions follow a simple paradigm that if a role has update permissions on a parent data object, the same role will have insert, update, and delete permissions on child data objects.
Explicit permissions are required only for the objects mentioned in Table 12-7, "Data Objects Requiring Explicit Insert/Update/Delete Permissions". The rest of the data objects either have derived or implicit permissions.
While assigning data objects or fine-grained permissions to roles, Oracle Identity Manager uses the following permission model:
To modify an insert data permission, a user who is logged in must have the insert and update permissions.
To modify an update data permission, a user who is logged in must have the update permissions.
To modify a delete data permission, a user who is logged in must have the insert, update, and delete permissions.
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 system-managed Uncategorized role category. If the value in LDAP has multiple values or a single, unrecognized value, 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 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.
This section describes the following topics:
To create a role category:
Login to Oracle Identity Administration.
In the Welcome page, under Roles, click Create Role Category.
Alternatively, in the Browse tab of the left pane, expand Roles, and from the Actions menu, select Create Category. Otherwise, click Create Category icon on the toolbar.
The Create Role Category page is displayed.
In the Category Name box, enter the name of the role category.
In the Description box, enter a description for the role category. This step is optional.
Click Save. A page is displayed with a message on the top of the page stating that the role category is created. 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.
To search for role categories:
In the Welcome page, under Roles, click Advanced Search - Role Categories. The Advanced Search: Categories page is displayed.
In the Category Name field, enter a search criterion. You can enter the asterix wildcard character (*) in the search criterion.
From the list adjacent to the Category Name field, select a search comparator. The default search comparator is Begins With. However, Equals search comparator can be used.
If you want to add a field to the search condition, then click Add Fields. From the list, select Description. The Description field is added to the Advanced Search: Categories page. You can specify a search criterion in the Description field to search by description.
To remove the Description field from the search condition, click the cross icon adjacent to the Description field.
Click Search. The categories that match search criteria you specified are displayed in the search results table.
To modify a role category:
In the Browse tab of the left pane, expand Roles.
Select the role category that you want to modify.
From the Actions menu, select Open. Alternatively, click the Open Role or Category Detail icon on the toolbar. A page with details about the role category is displayed.
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.
Click the Roles tab. In this tab, you can view all roles that are assigned to this category.
To view role details assigned to a role category:
In the Roles tab of the role category details page, select the role that you want to view details.
From the Actions menu, select Open (Open Role Detail). Alternatively, you can click Open (Open Role Detail) on the toolbar. The Role Detail page for the selected role is displayed.
To delete a role category:
In the browse tree for roles in the left pane, select a role category that you want to delete.
From the Actions menu, select Delete. Alternatively, click the Delete icon on the toolbar. If the role category detail page is open, then click Delete Role Category on the toolbar. A message box is displayed asking for confirmation.
Click Yes. The role category is deleted.
When a user logs in to Oracle Identity Manager, the links, buttons, and menus associated with the actions that the user can perform are displayed. For example, on the Welcome page of Oracle Identity Manager Administration, the Advanced Search - Roles link is displayed if the user is authorized to perform advanced search for roles. The actions that the user is authorized to perform is determined by the authorization policies. These authorization policies are defined for Oracle Identity Manager and stored in Oracle Entitlements Server (OES). The policies are enforced at runtime to control the authorization to perform various tasks in the UI.
See Also:
Chapter 15, "Managing Authorization Policies" for detailed information about authorization policiesAuthorization policies control the access to various operations with the help of permissions. Table 12-8 lists the permissions for role management operations:
Table 12-8 Role Management Permissions
Permission | Description |
---|---|
Create Role |
Determines if the user can create a role Note: This permission is not associated with a specific role. |
Modify Role Detail |
Determines if the user can update a specific role |
Delete Role |
Determines if the user can delete a specific role |
View Role Detail |
Determines if the user can view a specific role and the complete hierarchy of the specific role |
Search for Role |
Determines if the user can search for roles Note: This permission is not associated with a specific role. |
Modify Role Membership |
Determines if the user can grant or revoke a specific role to a user. |
Modify Role Hierarchy |
Determines if the user can add or remove a child role to or from a specific role |
View Role Membership |
Determines the user to whom the specific role is granted |
Create Role Category |
Determines is the user can create a role category Note: This permission is not associated with a specific role category or role. |
Modify Role Category |
Determines if the user can update a role category Note: This permission is not associated with a specific role category or role. |
Delete Role Category |
Determines if the user can delete a role category Note: This permission is not associated with a specific role category or role. |
View Role Category Detail |
Determines if the user can view the details of a role category Note: This permission is not associated with a specific role category or role. |
Search for Role Categories |
Determines if the user can search for role categories Note: This permission is not associated with a specific role category or role. |
Note:
When a role is granted to a user, the Modify Role Membership permission must be granted to the specific role that you are trying to grant.Permissions are enforced by authorization policies, which regulate the way permissions are granted. The default authorization policies for the role management feature allow Oracle Identity Manager to function properly. Without these policies, you cannot access or perform any task in Oracle Identity Manager. This applies to the administrators and users.
You can create custom authorization policies to enforce delegated administration by using the Authorization Policy tab of Oracle Identity Administration. The following must be specified while creating an authorization policy:
Policy name and description
Oracle Identity Manager feature for which the policy is being created
Set of permissions associated with various actions
Assignment of policy to roles decides who gets the permissions via the role membership
Data constraint, which is a set of roles on which the actions specified in the policy can be performed. Hierarchy is supported in the data constraints. Therefore, all roles that are part of the hierarchy are included in the data constraint. This allows you to create a simple policy with only few roles listed in the constraint, but that includes a much bigger set of roles based on the hierarchy.
See Also:
"Role Management" for information about the default authorization policies for this feature
"Creating an Authorization Policy for Role Management" for information about creating custom authorization policies for role management
You can configure Oracle Identity Manager to generate 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. In addition, if Segregation of Duties (SoD) check for role grants is enabled, then you must also configure request-based role grants. However, request-based role grant can be enabled without enabling SoD check for role grants.
See Also:
"Using Segregation of Duties (SoD)" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager for information about SoDTo configure request-based role grants, you must set the values of the XL.RM_REQUEST_ENABLED and XL.RM_ROLE_ASSIGN_TEMPLATE system properties. For a description of these system properties and possible values, see "System Properties in Oracle Identity Manager" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.
If the XL.RM_REQUEST_ENABLED system property is not present or no legal value has been specified for this property, then role grants are performed without any request being generated. If XL.RM_REQUEST_ENABLED is true, and XL.RM_ROLE_ASSIGN_TEMPLATE has not been set or has an illegal value, then an error message is displayed, no role grant is performed, and a role request is not generated.
After a role grant request is generated, the request ID is displayed in the Administrative and User Console. This is for tracking the request in the Self Service or Advanced Administration.
Role grant requests have the following details:
Request ID: Automatically generated
Request Type: Based on the request template
Request Status: Assigned
Date Requested: Current timestamp
Effective Date: Current timestamp
Requester: Null
Beneficiary: Null
Justification: Null