21.1 About workflow-based provisioning
A key feature of Identity Manager is workflow-based provisioning, which is the process of managing user access to secure resources in an organization. These resources may include digital entities such as user accounts, computers, and databases. In this release, provisioned resources are mapped to Identity Manager entitlements.
Identity Manager can service a wide range of provisioning requests. Provisioning requests are user or system actions intended to grant or revoke access to organizational resources. They can be initiated directly by the end user through the Identity Manager user application, or indirectly in response to events occurring in the identity vault (eDirectory).
When a provisioning 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 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.
Some workflows require that processing proceed in a sequential fashion, with each approval step being performed sequentially. Other workflows provide support for parallel processing. When you define a provisioning request, you specify whether you want the workflow to support sequential or parallel processing.
Identity Manager provides a set of Web-based tools that the administrator can use to build provisioning capabilities into the user application. These tools give you the ability to configure provisioning requests and also manage workflows that are in process. To configure a provisioning request, the administrator creates a provisioning request definition, which binds the resource to a workflow.
21.1.1 High-level architecture
The following diagram shows the high-level architecture of the workflow-based provisioning system included with Identity Manager:
The sections below describe each component of this architecture.
Provisioning Web interface
The Identity Manager user application provides a Web interface through which end users submit provisioning requests and manage these requests once they’ve been submitted. The user application also provides the User Application Administrator or an Organizational Manager with the ability to assign delegates and proxies for provisioning workflows.
HINT:The provisioning and workflow actions are available on the Requests & Approvals tab of the Identity Manager user application.
For more information on delegates and proxies, see Section 21.3, Provisioning security. For complete details on working with the user application, see the Identity Manager User Application: User Guide.
iManager Administration Tools
iManager provides plug-ins you can use to configure and manage provisioning requests and their associated workflows.
To configure a provisioning request, you bind it to a provisioned resource, specify the runtime characteristics of the associated workflow, and enable it for use. Once a provisioning request has been initiated, you can use iManager to view the status of the workflow process, reassign activities within the workflow, or terminate the workflow in the event that it is stuck.
Identity Manager User Application Driver
In addition to supporting end user requests to provision resources, Identity Manager allows you to initiate provisioning requests in response to events occurring in eDirectory. The Identity Manager User Application Driver listens for events and responds by initiating the corresponding provisioning requests. These requests may in turn initiate workflows to handle the approval process. For example, if configured to do so, Identity Manager will support a scenario in which the addition of a new user in eDirectory automatically kicks off a predesignated provisioning request and workflow.
Provisioning System
The Provisioning System performs all processing required to initiate and fulfill provisioning requests. If a request requires one or more approvals, the Provisioning System in turn calls the Workflow System to start the workflow process. Once the necessary approvals have been given, the Provisioning System provisions the resource as requested.
The Provisioning System maintains information about available and outstanding provisioning requests in the identity vault (eDirectory).
To initiate a request or perform the processing required to fulfill a request, the system accesses the identity vault through the Directory Abstraction Layer.
For details on the Directory Abstraction Layer, see Section 4.0, Configuring the Directory Abstraction Layer.
Workflow System
When a provisioning request requires one or more approvals, the Workflow System coordinates the approval process. During the course of processing, it interacts with these components:
-
Workflow database
-
Scripting engine
-
Audit
-
SMTP
-
Security system
Workflow database
To track the state of workflows in process, the Workflow System stores information in a database. This database maintains information about workflow process instances, work lists (queues), and workflow addressees. In addition, it stores any comments added during the execution of a workflow process.
Scripting engine
The Workflow System calls the Scripting engine whenever a workflow includes a dynamic expression that must be evaluated. Dynamic expressions can include variables, functions, and operators, as well as references to entities in the Directory Abstraction Layer.
Novell Audit
To log information about the state of a workflow process, the Workflow System interacts with Novell Audit. During the course of its processing, a workflow may log information about various events that have occurred. Users can then use the Novell Audit reporting tools to look at logging data.
For details on setting up logging, see Section 5.0, Setting up Logging. For details on controlling the levels of logging messages you want the Identity Manager user application to generate, see Section 12.0, Logging Configuration.
SMTP
A workflow process often sends e-mail notifications at various points in the course of its execution. For example, an e-mail might be sent when a workflow activity is assigned to a new addressee.
An administrator can edit an e-mail template in iManager and then use this template in a workflow process. At runtime, the Workflow System retrieves it from eDirectory and replaces tags with dynamic text suitable for the notification.
E-mail notifications are handled through the Simple Mail Transfer Protocol (SMTP).
For basic setup steps required for e-mail notification, see Section 23.3, Configuring the e-mail server and Section 23.4, Working with the installed e-mail template. For details on configuring e-mail notification for a workflow, see Configuring the workflow activities.
Security
The Security system handles all aspects of security for a workflow-based provisioning application.
For more information on workflow security, see Section 21.3, Provisioning security.
21.1.2 Provisioning and workflow example
Suppose a user needs an account on an IT system. To set up the account, the user initiates a request through the Identity Manager user application. This request starts a workflow, which coordinates an approval process. Once the necessary approvals have been granted, the request is fulfilled. There are three basic steps in the process, as outlined below.
Step 1: Initiating the request
In the Identity Manager user application, the user browses a list of resources by category and selects one to provision. In the identity vault, the provisioned resource selected is associated with a provisioning request definition. The provisioning request definition is the most prominent object in a provisioning system. It binds a provisioned resource to a workflow, and acts as the means by which the workflow process is exposed to the end user. The provisioning request definition provides all the information required to display the initial request form to the user, and to start the flow that follows the initial request.
In this example, the user selects the New Account resource. When the user initiates the request, the Web application retrieves the initial request form and the description of the associated initial request data from the Provisioning System, which gets these objects from the provisioning request definition.
When a provisioning request is initiated, the Provisioning System tracks the initiator and the recipient. The initiator is the person who made the request. The recipient is the person for whom the request was made. In some situations, the initiator and the recipient may be the same individual.
Each provisioning request has an operation associated with it. The operation specifies whether the user wants to grant or revoke the resource.
Step 2: Approving the request
Once the user has initiated a request, the Provisioning System starts the workflow process. The workflow process coordinates the approvals. In this example, two levels of approvals are required, one from the user’s manager, and a second from the manager’s supervisor. If approval is denied by any user in a workflow, the flow terminates and the request is denied.
NOTE:Identity Manager ships with a set of provisioning request templates that support up to five levels of workflow approval. In a follow-on release of Identity Manager, the Eclipse-based design environment will provide tools that let you create your own custom workflow processes. For more information on the templates that ship with this release, see Section 22.2, Working with the installed templates.
Workflows can process approvals in a sequential manner, or in a parallel manner. In a sequential workflow, each approval task must be processed before the next approval task begins. In a parallel workflow, users can work on the approval tasks simultaneously.
Sequential flow Here’s the basic design pattern of a sequential workflow with two approvals:
Parallel flow Here’s the basic design pattern of a parallel workflow with two approvals:
NOTE:The display labels (First approval, Second approval, and so on) can easily be changed to suit your application requirements. For parallel flows, you may want to specify labels that do not imply sequential processing. For example, you might want to assign labels such as One of Three Parallel Approvals, Two of Three Parallel Approvals, and so on.
The workflow definition is made up of these components
Start activity The workflow process begins with the execution of the Start activity. This activity initializes a work document using the initial request data. It also binds several system values such as the initiator and recipient, so that these can be used in script expressions.
User activities After the Start activity finishes execution, the Workflow System forwards processing to the first User activity in the flow. A User activity is an activity that supports user interactions. To handle these interactions, the activity displays a form, which gives the user the ability to act on the request. In the workflow examples shown above, First approval and Second approval are examples of User activities. The display labels for User activities can be localized to satisfy international requirements.
A User activity may support one or more of these actions:
-
Claim
-
Approve
-
Deny
-
Refuse
-
Reassign (available to Organizational Managers and User Application Administrators only)
NOTE:The fields and buttons on the form will vary depending on which resource is requested and how the workflow is configured. The Refuse action, for example, is not supported by many of the templates shipped with the product.
A User activity has five possible outcomes:
-
Approved
-
Denied
-
Refused
-
Error
-
Timeout
NOTE:The Error and Timeout outcomes may occur without any action being taken by the user.
If the user approves the request, the workflow forwards control to the next activity in the flow. If no further approvals are needed, the resource is provisioned. If the user denies the request, the work item is forwarded to the next activity in the workflow and the request is denied. Alternatively, the user can reassign the task (if he/she is an Organizational Manager or User Application Administrator), which puts the work item in another user’s queue.
NOTE:The provisioning request templates that ship with the product are configured to terminate a workflow process when a request is denied. When a request is denied, the workitem is forwarded to the Finish activity, which terminates the flow.
The user to whom a User activity has been assigned is referred to as the addressee. The addressee for an activity may be notified of the assigned task via e-mail. To perform the work associated with the activity, the addressee can click the URL in the e-mail, find the task in the work list (queue), and claim the task.
The addressee must respond to a User activity within a specified amount of time, or the activity times out. Typically the timeout interval is expressed in hours or days, to allow the user sufficient time to respond.
When an activity times out, the workflow process may try to complete the activity again, depending on the retry count specified for the activity. In some situations, the workflow process may be configured to escalate an activity that has timed out to another user. In this case, the activity is reassigned to a new addressee (the user’s manager, for example) to give this user an opportunity to finish the work of the activity. In the event that the last retry times out, the activity may be marked as approved or denied, depending on how the workflow was configured.
Conditional activities During the course of execution, a workflow process may perform a test and check the outcome to see what to do next. The Conditional activity provides this capability. Conditional activities use a scripting expression to define the condition to evaluate. In the workflow examples shown above, Approval Condition is an example of a Conditional activity.
Conditional activities support three possible outcomes:
-
True
-
False
-
Error
Branch and Merge activities In a workflow that supports parallel processing, the Branch activity allows two users to act on different areas of the workitem in parallel. Once the users have completed their work, the Merge activity synchronizes the incoming branches in the flow.
Provisioning activity The Provisioning activity fulfills the provisioning request. This activity is executed only if all of the necessary approvals have given.
For details on the provisioning step, see Step 3: Fulfilling the request.
Finish activity The Finish activity is the final activity in a workflow. When all the activities in a flow have been completed and the final result of the flow is available, the Finish activity can be executed. The Workflow System can determine the final state of the process by examining the links into the Finish activity. The overall flow state is approved when an approval link reaches the Finish activity. If any other outcome (deny, timeout, or error) leads into the Finish activity, the overall flow state is denied.
When a workflow process reaches the Finish activity with an approved state, the approval process is complete, and the provisioning request can be fulfilled.
Step 3: Fulfilling the request
When a provisioning request has been approved, the Workflow System can begin the provisioning step. At this point, control passes back to the Provisioning System.
To fulfill the provisioning request, the Provisioning System may execute an Identity Manager entitlement or directly manipulate an eDirectory object and its attributes. During the provisioning step, it creates any related objects and records the results of the provisioning action on the recipient, as described in the provisioning data definition. Depending on whether the user requested a grant or revoke operation, this may involve setting or removing the value of an attribute on the recipient, or adding an item to or removing an item from a multi-valued attribute on the recipient. The attributes involved are eDirectory attributes (possibly made available by adding an auxiliary class to the recipient). The attribute values themselves may be simple or they may be of a complex type that allows the Provisioning System to specify the value of internal sub-attributes.