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:

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:

The system roles are described in detail below:

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 .