Permissions represent the accounts, roles, and resources that apply to users. Your organization might automatically assign permissions or users might need to requeste them. For example, a user might receive a computer as part of the job, but then need to request access to a specific software application. Users request permssions through the Dashboard. Some requests require approval from a single individual; others require approval from several individuals. In some instances, a request can be fulfilled without any approvals.
Provisioning users encompasses the following elements:
A resource is any digital entity such as a user account, computer, or database that a business user needs to be able to access.
Each resource is mapped to an entitlement. A resource definition can have no more than one entitlement bound to it. A resource definition can be bound to the same entitlement more than once, with different entitlement parameters for each resource.
For more information, see Section 12.0, Creating and Managing Resources.
A role represents a hierarchy of permissions. For example, a corporate role called Sales Employee might consist of various child permissions that apply to all employees, such as Garage Access, Building Access, and Read Access to Company Intranet. The role might also have permissions specifically for sales employees, such as access to sales software applications and financial data.
You can map role assignments to resources within a company, such as user accounts, computers, and databases.
For more information, see Section 11.0, Creating and Managing Roles.
Separation of duties (SoD) policies help you manage potential conflicts between role assignments. For example, your organization might have two or more roles that could create security problems when assigned to the same individual. When a user requests one of these roles while already having a conflicting role or requests two or more conflicting roles, the identity applications respond according to the SoD policies.
For more information, see Section 2.2.1, Understanding Separation of Duties Constraints.
A process that coordinates the approval or revocation of a request for permissions. Each workflow can have automatic or manual triggers and can include email notifications.
Workflows take into account the methods required for approving and revoking a role or resource. For example, the SAP software application might require two levels of approval: first from the user’s manager and second from the resource manager for the application.
For more information, see Section 2.2.2, Understanding Workflow-Based Provisioning.
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.
Workflow-based provisioning allows you to initiate workflow processes to manage the approval and revocation of user access to your organization’s secure systems.
The Work Dashboard tab in the User Application allows users to make workflow provisioning requests. A provisioning request is a user or system action intended to initiate a process, and can be in the following ways:
Directly by the user through the Work Dashboard tab
Indirectly in response to events occurring in the Identity Vault
When a provisioning request requires permission from one or more individuals in an organization, the request starts one or more workflows. The workflows coordinate the approvals needed to fulfill the request. Some provisioning requests require approval from a single individual; others require approval from several individuals. In some instances, a request can be fulfilled without any approvals.
By default, the Work Dashboard tab does not display any provisioning requests. To configure a provisioning request, a designer familiar with your business needs creates a provisioning request definition, which binds the resource to a workflow.
The designer can configure workflows that proceed in one of the following ways:
Sequential fashion, with each approval step being performed in order
Parallel fashion, which allows more than one user to act on a workflow task concurrently
Identity Manager provides a set of Eclipse-based tools for designing the data and the flow of control within the workflows. In addition, Identity Manager provides a set of Web-based tools that allow users to view existing provisioning requests and manage workflows that are in process. For more information, see Section 2.5, Design and Configuration Tools.
The Provisioning Administrator is responsible for managing the workflow-based provisioning features of the User Application. For more information, see Section 2.4, Understanding the Types of Users for the Identity Applications.
The Dashboard includes an email-based approvals feature that enables the identity applications to send an email notifying users that they need to review a permission request. The notification can include action links that correspond to Approve and Reject so users can more easily respond to the request. Email-based approvals also supports digital signatures to ensure authentication of the message content.
You enable email-based approvals in the Dashboard and configure your Provisioning Request Definitions to support the feature. For more information, see the following sources:
Help in the Identity Manager Dashboard.
Email Based Approval
in the NetIQ Identity Manager - Administrator’s Guide to Designing the Identity Applications