Roles based workflows must follow the same guidelines outlined in Guidelines for Creating Workflows. In addition, roles based workflows have their own unique requirements. They are described in the following sections:
Role approval workflows are specialized workflows that provide support for role approval and revocation on the User Application’s Roles tab. The Roles Based Provisioning Module includes a read-only Role Approval workflow (named Role Approval) whose design pattern supports:
The ability to process role approvals in either serial or quorum mode.
The retrieval of approver DNs from the role object (nrfRequest). If you create a custom workflow, the approvers must be defined in the workflow. However, this might lead to addressee evaluation problems and less security concerning who can approve a role.
The ability to display the role using localized display names.
All nrfRequest object mappings for request and approval forms.
Logging and reporting functions.
Read-only display of request information. The role approval workflow does not allow changes to the request. Approvers have only the ability to approve or deny the role request.
An email notification is sent to all approvers of role approval workflows. A completed notification email is sent upon completion of the role approval workflow. The recipient email address is used when the workflow is intended to be assigned to a user identity.
This pattern is shown in Figure 6-6.
Figure 6-6 Default Role Approval Workflow
The components of this workflow, and their responsibilities are summarized in Table 6-9.
Table 6-9 Standard Role Approval Activities
Activity Name |
Activity Type |
Description |
---|---|---|
Start |
Start |
Logical starting point for all workflows. For role approvals it must instantiate the nrfRequest object. |
Set up counter |
Mapping |
Sets up the counter for the number of approvers in case the mode is Serial. |
Localize Display |
Mapping |
Sets up the display labels for each of the associated display names for the user’s locale. |
Check for Processing Type |
Condition |
Determines whether the approval is a quorum condition by setting the Condition property to this ECMA expression: nrfRequest.isQuorumProcess() If the quorum condition exists, control proceeds to the Approve Role Request (Quorum). If the quorum condition does not exist, control proceeds to the Approve Role Request (Serial). You specify the processing type for the role approval when you set up the Role Catalog. |
Approve Role Request (Quorum) |
Approval |
This is where the decision to approve or deny the request is recorded as part of the workflow instance. The quorum condition required to make the process successful is retrieved from the nrfQuorum attribute of the nrfRequest object. |
Approve Role Request (Serial) |
Approval |
This is where the decision to approve or deny the request is recorded as part of the data flow associated with the workflow instance. The workflow loops through the list of approvers found in the nrfRequest object. The request is approved if all approvers in the serial process approve the request. The request is denied upon the first rejection from an approver in the serial process |
Deny Assignment of Role |
Role Binding |
Changes the deny attribute in the nrfRequest object to true. |
Approve Assignment of Role |
Role Binding |
Changes the approve attribute in the nrfRequest object to true. |
Finish |
Finish |
Logical end point of all workflows. |
To use the standard Role Approval workflow in your user application, you must specify your own users as Trustees. For information on setting the Trustees property, see Modifying Settings of a Provisioning Request Definition.
If the standard role approval workflow does not support your business needs, and cannot be customized to do so, you can write your own. At a minimum, a custom role approval workflow must:
Contain two Role Binding activities
One Role Binding activity must be set to approved and the other set to denied. You must link each of the Role Binding activities to the Finish activity. If the workflow does not meet this requirement, it is invalid, and Designer prevents you from deploying it. The Role Service driver needs these values to set the status for the workflow and to then apply the logic to associate the role to the identity.
Contain the following control in the request form:
Form Field Name: nrfRequestDN
Data Type: Role Request
Control Type: Text
Instantiate the nrfRequestDN in the Pre Activity Data Item Mapping.
Contain the following in the Post Activity Data Item Mapping:
Source Form Field: nrfRequestDN
Target Expression: flowdata.nrfRequest/DN
Data Type: dn
Not contain the following ECMA expressions in the Data Item Mapping or Properties definitions because they might return null:
getApprovalDN()
getAllApproversDN()
getAllSodApproversDN()
Because Designer and the User Application user interface do not allow entry of approvers for custom role approval workflows, you must specify the approvers in the workflow itself. Therefore, if you create a custom workflow based on a copy of the Role Approval or SoD Conflict Approval provisioning request definitions, you must remove the ECMA methods from Data Item Mapping or Properties definitions.
In the following example, a user requests a role and the user’s manager approves it.
Figure 6-7 Sample Custom Role Approval Workflow
The components of this workflow, and their responsibilities are summarized in Table 6-10.
Table 6-10 Sample Custom Workflow Components
Activity Name |
Activity Type |
Description |
---|---|---|
Start |
Start |
Logical starting point of all workflows. |
Localize Display |
Mapping |
Sets up the display labels for the user’s locale. |
Manager Approval |
Approval |
This is where the decision to approve or deny the request is recorded as part of the workflow instance. The role request approval is needed only by the requestor’s manager. |
Approve Assignment of Role |
Role Binding |
Changes the approve attribute in the nrfRequest object to true. |
Deny Assignment of Role |
Role Binding |
Changes the deny attribute in the nrfRequest object to true. |
Finish |
Finish |
Logical end point of all workflows. |
The data item mapping for the sample custom role approval workflow is defined in Table 6-11
Table 6-11 Sample Custom Role Approval Workflow Data Item Mapping
Activity Name |
Property Type |
Property Value |
---|---|---|
Start |
Data Item Pre Activity |
Source Expression: None Target Form Field: nrfRequestDN Data Type: dn |
|
Data Item Post Activity |
Source Form Field: nrfRequestDN Target Expression: flowdata.nrfRequest/DN Data Type: DN |
Localize Display |
Data Item Source and Target mapping |
|
Manager Approval |
Addressee Property |
Addressee IDVault.get(recipient,'user','manager') |
|
Data Item Pre Activity |
|
|
Data Item Post Activity |
None |
Approve Assignment of Role |
Action Property |
approved |
Deny Assignment of Role |
Action Property |
denied |
Finish |
|
None |
Separation of Duties approval workflows are specialized workflows that allows a Separation of Duties constraint to be overridden. The Roles Based Provisioning Module includes a read-only Separation of Duties Approval workflow (named SoD Conflict Approval) whose design pattern supports:
The ability to process SoD conflicts in either serial or quorum mode.
The retrieval of SoD approver DNs from the request object (nrfRequest). If you create a custom workflow, the approvers must be defined in the workflow; however, this might lead to addressee evaluation problems and less security concerning who can approve an SoD.
The ability to display the SoD using localized display names.
All nrfRequest object mappings for request and approval forms.
Logging and reporting functions.
Read-only display of requests. Approvers can only approve or deny the SoD conflict.
An email notification is sent to all approvers per SoD conflict found for SoD workflow approvals. A completed notification email is sent upon completion of the SoD approval workflow. The recipient email address is used when the workflow is intended to be assigned to a user identity.
This pattern is shown in Figure 6-6.
The roles subsystem allows one Separation of Duties approval flow for the Role subsystem. If you choose to use a custom SoD approval flow, make sure that it works for all SoD situations.
Figure 6-8 Standard SoD Approval Workflow
The components of the workflow are described in the following table:
Table 6-12 Standard SoD Constraint Exception Approval Workflow Activities
Activity Name |
Activity Type |
Description |
---|---|---|
Start |
Start |
Logical starting point of all workflows. |
Localize Display |
Mapping |
Sets up the display labels for each of the associated Display Names for the user’s locale for the SoD conflicting Role. |
Localize SoD Name |
Mapping |
Sets up the display labels for each of the associated Display Names for the user’s locale for the SoD conflicting Role. |
Check for Processing Type |
Condition |
Determines whether the approval is a quorum condition by setting the Condition property to this ECMA expression: nrfRequest.isSodQuorumProcess() If the quorum condition exists, control proceeds to the Approve SoD Conflict (Quorum). If the quorum condition does not exist, control proceeds to the Approve SoD Conflict (Serial). You specify the processing type for the role approval when you set up the Role Catalog. |
Approve SoD Conflict (Quorum) |
Approval |
This is where the decision to approve or deny the request is recorded as part of the workflow instance. The quorum condition required to make the process successful is retrieved from the nrfQuorum attribute of the nrfRequest object. |
Approve SoD Conflict (Serial) |
Approval |
This is where the decision to approve or deny the request is recorded as part of the data flow associated with the workflow instance. The workflow loops through the list of approvers found in the nrfRequest object. The request is approved if all approvers in the serial process approve the request. The request is denied upon the first rejection from an approver in the serial process |
Deny SoD Conflict |
Role Binding |
Changes the deny attribute in the nrfRequest object to true. |
Approve SoD Conflict |
Role Binding |
Changes the approve attribute in the nrfRequest object to true. |
Has More SoD Conflicts and Increment SoD Counter |
Condition and Mapping activity |
Loops through the SoD requests. |
Finish |
Finish |
Logical end point of all workflows. |
Separation of Duties conflict approval workflows are complex. Therefore, it is not recommended that you write a custom version. Rather, it is recommended that you add new activities to a copy of the standard SoD approval workflow. For example, you might want to add additional logging or messages. This example illustrates a customized workflow that includes a new logging activity.
Figure 6-9 Adding Activities to the SoD Workflow
The Log Activity properties are shown in Figure 6-10.
Figure 6-10 Log Activity Properties
SoD Conflict approval workflows must follow the same rules as the role approval workflows as described on Writing Custom Role Workflows.