6.6 Guidelines for Creating Roles Based Workflows

Roles based workflows must follow the same guidelines outlined in Section 6.5, Guidelines for Creating Workflows. In addition, roles based workflows have their own unique requirements. They are described in the following sections:

6.6.1 About Role Approval Workflows

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 e-mail notification is sent to all approvers of role approval workflows. A completed notification e-mail is sent upon completion of the role approval workflow. The recipient e-mail address is used when the workflow is intended to be assigned to a user identity. For assignments to a group, container, or another role, the role owner’s e-mail address is used.

This pattern is shown in Figure 6-7.

Figure 6-7 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 Roles 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 Section 4.2.6, Using the Overview Tab to Modify Basic Settings.

6.6.2 Writing Custom Role Workflows

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.nrfRequestDN

    • 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-8 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.

Data Item Mapping for Sample Custom Role Approval Workflow

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

6.6.3 About Separation of Duties Approval Workflows

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 e-mail notification is sent to all approvers per SoD conflict found for SoD workflow approvals. A completed notification e-mail is sent upon completion of the SoD approval workflow. The recipient e-mail address is used when the workflow is intended to be assigned to a user identity. For assignments to a group, container, or another role, the role owner’s e-mail is used.

This pattern is shown in Figure 6-7.

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-9 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 conflcting 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 Roles 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.

6.6.4 Customizing the Standard Separation of Duties Workflow

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-10 Adding Activities to the SoD Workflow

The Log Activity properties are shown in Figure 6-11.

Figure 6-11 Log Activity Properties

SoD Conflict approval workflows must follow the same rules as the role approval workflows as described on Section 6.6.2, Writing Custom Role Workflows.