13.1 About the Roles and Resources Tab
The purpose of the tab is to give you a convenient way to perform roles-based provisioning actions. These actions allow you to manage role definitions and role assignments within your organization, as well as resource definitions and resource assignments. Role assignments can be mapped to resources within a company, such as user accounts, computers, and databases. Alternatively, resources may be assigned directly to users. For example, you might use the tab to:
-
Make role and resource requests for yourself or other users within your organization
-
Create roles and role relationships within the roles hierarchy
-
Create separation of duties (SoD) constraints to manage potential conflicts between role assignments
-
Look at reports that provide details about the current state of the Role Catalog and the roles currently assigned to users, groups, and containers
When a role or resource assignment request requires permission from one or more individuals in an organization, the request starts a workflow. The workflow coordinates the approvals needed to fulfill the request. Some assignment requests require approval from a single individual; others require approval from several individuals. In some instances, a request can be fulfilled without any approvals.
NOTE:Role approvals are triggered for explicit role-to-user assignments only.
When a role assignment request results in a potential separation of duties conflict, the initiator has the option to override the separation of duties constraint, and provide a justification for making an exception to the constraint. In some cases, a separation of duties conflict can cause a workflow to start. The workflow coordinates the approvals needed to allow the separation of duties exception to take effect.
Your workflow designer and system administrator are responsible for setting up the contents of the tab for you and the others in your organization. The flow of control for a workflow, as well as the appearance of forms, can vary depending on how the approval definition for the workflow was defined in the Designer for Identity Manager. In addition, what you can see and do is typically determined by your job requirements and your level of authority.
13.1.1 About Roles
This section provides an overview of terms and concepts used in the tab:
Roles and Role Assignments
A role defines a set of permissions related to one or more target systems or applications. The tab allows users to request role assignments, which are associations between a role and a user, group, or container. The tab also allows you to define role relationships, which establish associations between roles in the roles hierarchy.
You can assign roles directly to a user, in which case these direct assignments give a user explicit access to the permissions associated with the role. You can also define indirect assignments, which allow users to acquire roles through membership in a group, container, or related role in the role hierarchy.
NOTE:Role approvals are triggered for explicit role to user assignments only.
When you request a role assignment, you have the option to define a role assignment effective date, which specifies the date and time when the assignment takes effect. If you leave this blank, it means the assignment is immediate.
You can also define a role assignment expiration date, which specifies the date and time when the assignment will automatically be removed.
When a user requests a role assignment, the Role and Resource Subsystem manages the life cycle of the role request. To see which actions have been taken on the request by users or by the subsystem itself, you can check the status of the request on the tab in the .
Roles Catalog and Role Hierarchy
Before users can begin assigning roles, these roles must be defined in the . The is the storage repository for all role definitions and supporting data needed by the Role and Resource Subsystem. To set up the , a Role Module Administrator (or Role Manager) defines the roles and the roles hierarchy.
The roles hierarchy establishes relationships between roles in the catalog. By defining role relationships, you can simplify the task of granting permissions through role assignments. For example, instead of assigning 50 separate medical roles each time a doctor joins your organization, you can define a Doctor role and specify a role relationship between the Doctor role and each of the medical roles. By assigning users to the Doctor role, you can give these users the permissions defined for each of the related medical roles.
The roles hierarchy supports three levels. Roles defined at the highest level (called Business Roles) define operations that have business meaning within the organization. Mid-level roles (called IT Roles) supports technology functions. Roles defined at the lowest level of the hierarchy (called Permission Roles) define lower-level privileges. The following example shows a sample role hierarchy with three levels for a medical organization. The highest level of the hierarchy is on the left and the lowest level is on the right:
Figure 13-1 Sample Roles Hierarchy
A higher-level role automatically includes privileges from the lower-level roles that it contains. For example, a Business Role automatically includes privileges from the IT Roles that it contains. Similarly, an IT Role automatically includes privileges from the Permission Roles that it contains.
Role relationships are not permitted between peer roles within the hierarchy. In addition, lower-level roles cannot contain higher-level roles.
When you define a role, you can optionally designate one or more owners for that role. A role owner is a user who is designated as the owner of the role definition. When you generate reports against the Role Catalog, you can filter these reports based on the role owner. The role owner does not automatically have the authorization to administer changes to a role definition. In some cases, the owner must ask a role administrator to perform any administration actions on the role.
When you define a role, you can optionally associate the role with one or more role categories. A role category allows you to categorize roles for the purpose of organizing the roles system. After a role has been associated with a category, you can use this category as a filter when browsing the Role Catalog.
If a role assignment request requires approval, the role definition specifies details about the workflow process used to coordinate approvals, as well as the list of approvers. The approvers are those individuals who can approve or deny a role assignment request.
Separation of Duties
A key feature of the Role and Resource Subsystem is the ability to define separation of duties (SoD) constraints. A separation of duties (SoD) constraint is a rule that defines two roles that are considered to be in conflict. The Role Administrator/Role Manager creates the separation of duties constraints for an organization. By defining SoD constraints, they can prevent users from being assigned to conflicting roles, or maintain an audit trail to keep track of situations where violations have been allowed. In a separation of duties constraint, the conflicting roles must be at the same level in the roles hierarchy.
Some separation of duties constraints can be overridden without approval, whereas others require approval. Conflicts that are permitted without approval are referred to as separation of duties violations. Conflicts that have been approved are referred to as separation of duties approved exceptions. The Role and Resource Subsystem does not require approvals for SoD violations that result from indirect assignments, such as membership in a group or container, or role relationships.
If a separation of duties conflict requires approval, the constraint definition specifies details about the workflow process used to coordinate approvals, as well as the list of approvers. The approvers are those individuals that can approve or deny an SoD exception. A default list is defined as part of the Role and Resource Subsystem configuration. However, this list can be overridden in the definition of an SoD constraint.
Roles Reporting and Auditing
The Role and Resource Subsystem provides a rich reporting facility to help auditors analyze the Role Catalog, as well as the current state of role assignments and SoD constraints, violations, and exceptions. The roles reporting facility allows Roles Auditors and Roles Module Administrators to display the following types of reports in PDF format:
-
Role List Report
-
Role Assignment Report
-
SoD Constraint Report
-
SoD Violation and Exception Report
-
User Roles Report
-
User Entitlements Report
In addition to providing information through the reporting facility, the Role and Resource Subsystem can be configured to log events to Novell or OpenXDAS auditing clients.
Roles Security
The Role and Resource Subsystem uses a set of system roles to secure access to functions within the tab. Each menu action in the tab is mapped to one or more of the system roles. If a user is not a member of one of the roles associated with an action, the corresponding menu item is not displayed on the tab.
The system roles are administrative roles automatically defined by the system at install time for the purpose of delegated administration. These include the following:
-
Roles Administrator
-
Roles Manager
The system roles are described in detail below:
Table 13-1 System Roles
|
Role |
Description |
|---|---|
|
Roles Administrator |
A system role that allows members to create, remove, or modify all roles, and grant or revoke any role assignment to any user, group, or container. This role also allows members to run any report for any user. A person in this role can perform the following functions in the User Application with unlimited scope:
|
|
Roles Manager |
A system role that allows members to modify roles and role relationships, and grant or revoke role assignments for users. A person in this role is able to perform the following functions in the User Application and is limited in scope by directory browse rights to the role objects:
|
Authenticated user
In addition to supporting the system roles, the Role and Resource Subsystem also allows access by authenticated users. An authenticated user is a user logged in to the User Application who does not have any special privileges through membership in a system role. A typical authenticated user can perform any of the following functions:
-
View all roles that have been assigned to the user.
-
Request assignment (for himself or herself only) to roles to which he or she has browse rights.
-
View request status for those requests for which he or she is either a requester or recipient.
-
Retract role assignment requests for those requests for which he or she is both requester and recipient.
Role and Resource Service Driver
The Role and Resource Subsystem uses the Role and Resource Service driver to manage back-end processing of roles. For example, it manages all role assignments, starts workflows for role assignment requests and SoD conflicts that require approvals, and maintains indirect role assignments according to group and container membership, as well as membership in related roles. The driver also grants and revokes entitlements for users based on their role memberships, and performs cleanup procedures for requests that have been completed.
What happens when entitlements change for a resource If you change the entitlement for an existing resource, the driver does not grant the new entitlement for users who are currently assigned the resource. To grant the new entitlement, you need to remove and reassign the resource to the users who need the entitlement.
For details on the Role and Resource Service driver, see the NetIQ Identity Manager User Application: Administration Guide.