14.1 About the Roles Tab

The purpose of the Roles 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. Role assignments can be mapped to resources within a company, such as user accounts, computers, and databases. For example, you might use the Roles tab to:

When a role 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 role 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.

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 Roles tab for you and the others in your organization. The flow of control for a roles-based workflow or separation of duties 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.

Roles and Proxy mode

Proxy mode works only on the Requests & Approvals tab and is not supported on the Roles tab. If you enter proxy mode on the Requests & Approvals tab, and then switch to the Roles tab, proxy mode is turned off for both tabs.

14.1.1 About Roles

This section provides an overview of terms and concepts used in the Roles tab:

Roles and Role Assignments

A role defines a set of permissions related to one or more target systems or applications. The Roles tab allows users to request role assignments, which are associations between a role and a user, group, or container. The Roles 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.

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 Roles Subsystem manages the life cycle of the role request. To see which actions have been taken on the request by users or by the Roles Subsystem, you can check the status of the request on the View Request Status page.

Roles Catalog and Role Hierarchy

Before users can begin assigning roles, these roles must be defined in the Role Catalog. The Role Catalog is the storage repository for all role definitions and supporting data needed by the Roles Subsystem. To set up the Role Catalog, 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 14-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 Roles 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 Security Officers create the separation of duties constraints for an organization. By defining SoD constraints, these officers 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 Roles 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 Subsystem configuration. However, this list can be overridden in the definition of an SoD constraint.

Roles Reporting and Auditing

The Roles 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 Detail 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 Roles Subsystem can be configured to log events to NovellĀ® Audit.

Roles Security

The Roles Subsystem uses a set of system roles to secure access to functions within the Roles tab. Each menu action in the Roles 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 Roles 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 Module Administrator

  • Roles Manager

  • Roles Auditor

  • Security Officer

The system roles are described in detail below:

Table 14-1 System Roles

Role

Description

Roles Module 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:

  • Create, remove, and modify roles.

  • Modify role relationships for roles.

  • Request assignment of users, groups or containers to roles.

  • Create, remove, and modify SoD constraints.

  • Browse the Role Catalog.

  • Configure the Roles Subsystem.

  • View the status of all requests.

  • Retract role assignment requests.

  • Run any and all reports.

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:

  • Create new roles and modify existing roles to which the user has browse rights.

  • Modify role relationships for roles to which the user has browse rights.

  • Request assignment of users, groups, or containers to roles to which the user has browse rights.

  • Browse the Role Catalog (limited in scope by browse rights).

  • Browse role assignment requests for users, groups, and containers (limited in scope by directory browse rights to role, user, group, and container objects).

  • Retract role assignment requests for users, groups, and containers (limited in scope by directory browse rights to role, user, group, and container objects).

Roles Auditor

A system role that allows members to run any reports to which they have directory browse rights.

Security Officer

A system role that allows members to create, remove, or modify SoD constraints. The Security Officer must have browse rights to the SoD constraints.

Authenticated user

In addition to supporting the system roles, the Roles 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 Service Driver

The Roles Subsystem uses the Role 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.

For details on the Role Service driver, see the Identity Manager User Application: Administration Guide.