17.3 Configuring a Provisioning Request Definition

Before configuring a provisioning request definition, you need to select the Identity Manager User Application driver that contains the definition. Having selected the driver, you can create a new provisioning request definition or edit an existing definition. You can also delete provisioning request definitions, change the status of a request definition, or define rights for a request definition.

17.3.1 Selecting the Driver

To select an Identity Manager User Application driver:

  1. Select the Identity Managercategory in iManager.

  2. Open the Provisioning Request Configuration role.

  3. Click the Provisioning Requests task.

    iManager displays the User Application Driver panel.

  4. Specify the driver name in the User Application Driver field, then click OK.

    iManager displays the Provisioning Request Configuration panel. The Provisioning Request Configuration panel displays a list of available provisioning request definitions.

    The installed templates appear in dark text with a status of Template. Request definitions that are templates do not display hypertext links because they are read only.

    NOTE:If the request definitions were configured to use localized text, the names and descriptions for these definitions show text that is suitable for the current locale.

Changing the driver. When you have selected a driver, the driver selection remains in effect for the duration of your iManager session, unless you select a new driver. To select a new driver, click the Actions command, then choose Select User Application Driver from the Actions menu.

17.3.2 Creating or Editing a Provisioning Request

To create a new provisioning request:

  1. Click the name of the provisioning request you want to use as a template in the Provisioning Request Configuration panel.

  2. Click the Create From command in the Provisioning Request Configuration panel.

    The first page of the Configure New Provisioning Request wizard displays.

  3. Type a common name for the new object in the Name field.

  4. For each language you want to support in your application, type the localized text in the Display Name and Description fields under Provisioning Request Localized Strings. This text is used to identify the provisioning request throughout the User Application.

  5. To add a new language to the list, click Add, then select the desired language.

    By default, a newly created provisioning request supports only English.

  6. Click Next.

  7. Specify the provisioned resource for the request definition, as described in Specifying the Provisioned Resource.

  8. Configure the activities for the workflow associated with the request definition, as described in Configuring the Workflow Activities.

  9. Specify the access rights for the request definition, as described in Specifying the Access Rights for the Provisioning Request.

  10. Specify the initial status for the request definition, as described in Specifying the Initial Status of the Provisioning Request.

  11. Review your settings, then click Finish.

To edit an existing provisioning request:

  1. Click the name of the provisioning request in the Provisioning Request Configuration panel.

    You are not permitted to edit a provisioning request that is a template. Request definitions that have a status of Template do not display hypertext links because they are read only.

    If you have a large number of request definitions, you might want to sort the list by a particular column, such as the Name or Description. To sort by a particular column, click the column heading.

  2. For each language you want to support in your application, click the check box beside the language in the list under Provisioning Request Localized Strings, then type the localized text in the Display Name and Description fields. This text is used to identify the provisioning request throughout the User Application.

  3. To add a new language to the list, click Add, then select the desired language.

    By default, a newly created provisioning request supports only English.

  4. Click Next.

  5. Specify the provisioned resource for the request definition, as described in Specifying the Provisioned Resource.

  6. Configure the activities for the workflow associated with the request definition, as described in Configuring the Workflow Activities.

  7. Specify the access rights for the request definition, as described in Specifying the Access Rights for the Provisioning Request.

  8. Specify the initial status for the request definition, as described in Specifying the Initial Status of the Provisioning Request.

  9. Review your settings, then click Finish.

Specifying the Provisioned Resource

This section provides instructions for specifying a provisioned resource that is based on an entitlement. It does not provide conceptual information about entitlements or instructions for creating and using entitlements.

For complete details on entitlements, see the Novell Identity Manager: Administration Guide.

To specify the provisioned resource:

  1. To use the target that is currently associated with the request definition, select Provisioned resource.

    Provisioned resource is selected by default if you’re editing a request definition that refers to a valid resource. If you’re defining a new provisioning request, this option is not selected.

  2. To bind the request definition to another resource that was previously defined within the currently selected driver, select Available provisioned resources, then pick a target from the drop-down list.

    If the request definition was bound to a resource that is not an entitlement, you are not permitted to change the resource.

  3. Select a category for the provisioned resource definition in the Category drop-down list.

    The category defaults to the category for the currently selected provisioned resource. Whenever you change the provisioned resource, the category for the request definition is also changed to match the category for the resource. If you want to assign a different category to the request definition, select that category in the Category drop-down list.

  4. To create a new resource based on an Identity Manager entitlement, click the + icon.

    To edit an existing resource, click the pen icon.

    To define the characteristics of the resource:

    1. Specify the name for the resource in the Name (CN) field.

    2. Select a category for the resource in the Category drop-down list.

    3. Specify the entitlement in the Entitlement field.

    4. For each language you want to support in your application, click the check box beside the language in the list under Provisioned Resource Localized Strings, then type the localized text in the Display Name and Description fields. This text is used to identify the provisioning resource throughout the User Application.

    5. To add a new language to the list, click Add, then select the desired language.

      By default, a newly created provisioning resource supports only English.

  5. Click Next.

    The Provisioned Resource wizard displays a page to allow you to provide data for any parameters required for the entitlement.

  6. If the entitlement does not require any entitlement parameters, click Next.

    The Create New Provisioned Resource wizard displays the Summary page, which provides information about the resource you’re defining.

  7. Click Finish.

Configuring the Workflow Activities

To configure the activities for the associated workflow:

  1. Specify whether you want to enable e-mail notifications for the workflow by selecting or deselecting the Notify participants by e-mail check box.

  2. Specify whether a digital signature is required to initiate the provisioning request by selecting or deselecting the Digital signature required check box.

    1. If you enable the Digital signature required check box, specify whether the digital signature will use data or form as its type:

      • Data specifies that the XML signature serve as the user agreement. When Data is selected, the XML data is written to the audit log.

      • Form specifies that a PDF document that includes the digital signature declaration be generated. This document serves as the user agreement. The user can preview the generated PDF document before submitting a request or approval. When Form is selected, the PDF document (encapsulated in XML) is written to the audit log.

      WARNING:You must use Novell Audit (or Sentinel) to preserve documents that you digitally sign. Digital signature documents are not stored in the User Application database, but are stored in the logging database. You must enable logging to preserve these documents.

    2. If you enable the Digital signature required check box, you also need to specify a digital signature confirmation string. To do this, click the Declarations icon.

      Type the signature confirmation string, then click OK.

  3. (Optional) For each workflow activity, change the display label by clicking the icon beside the name of the activity (in this case, Manager Approval).

    Type the display label in the Display Label field, then click OK.

    The default display labels (First approval, Second approval, and so on) suggest that approvals are processed sequentially. For parallel flows, you might 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.

  4. (Optional) For each workflow activity that supports quorums or multiple addressees, add additional addressees by clicking the Add another addressee to this user activity icon beside the name of the activity.

    When you click this button, a new Addressee section is presented on the page. You can use the controls in this section to define an expression or DN for the addressee (as described in the next step in this procedure). To delete the addressee, you can click the minus sign next to the addressee:

  5. For each workflow activity, also provide the following information:

    Field

    Description

    Reminder email

    Indicates whether reminder e-mail messages should be sent for this activity.

    Click the Edit this activity’s reminder email icon to configure reminder notifications. Specify these settings:

    • Start specifies when to send the first reminder. The start value is an offset from the time of the first assignment associated with the activity.

    • Interval specifies how often to send reminders after the first reminder has been sent.

    • Email Template specifies the language-independent name for the template to use for reminder e-mail messages. After the template name has been specified, the notification engine can determine which language-specific template to use at runtime.

      The language-independent template can have any name you like. The default template for reminder e-mail messages is called:

      Provisioning Reminder

      Each language-specific version of a template must have a suffix that provides a language code (for example, _fr for French, _es for Spanish, and so forth).

    Notification email

    Indicates whether notification e-mail messages should be sent for this activity.

    Click the Edit this activity’s notification email icon to configure notification e-mail messages. Specify these settings:

    • Email Template specifies the language-independent name for the template to use for notification e-mail messages. After the template name has been specified, the notification engine can determine which language-specific template to use at runtime.

      The language-independent template can have any name you like. The default template for notification e-mail messages is called:

      Provisioning Notification

      Each language-specific version of a template must have a suffix that provides a language code (for example, _fr for French, _es for Spanish, and so forth).

    • Replacement Parameters Map specifies one or more substitution values for the replacement parameters used in the e-mail template. To edit an existing value, click the replacement parameter, then specify an ECMAScript expression or fixed value. To add a new substitution value, click Add, select the target parameter, then specify an expression or fixed value.

    Digital signature required

    Indicates whether a digital signature is required to approve the request. Because each approval step might have more than one outgoing link, you need to specify whether a digital signature is required for each link.

    When you enable this check box, you are prompted to select the link for which a digital signature is required. Select the link, then click Close.

    If you enable the Digital signature required check box, specify whether the digital signature will use data or form as its type:

    • Data specifies that the XML signature serve as the user agreement. When Data is selected, the XML data is written to the audit log.

    • Form specifies that a PDF document that includes the digital signature declaration be generated. This document serves as the user agreement. The user can preview the generated PDF document before submitting a request or approval. When Form is selected, the PDF document (encapsulated in XML) is written to the audit log.

    If you enable the Digital signature required check box, you also need to specify a digital signature confirmation string. First, create an identifier for the string by selecting Create one in the Declarations list box. Then select the ID and click the Declarations icon.

    Type the signature confirmation string, then click OK.

    Approver Condition

    Specifies the approver condition for quorums.

    When the approver type for an activity is configured to support quorums, you can set the approver condition to define the number of approvers required to approve the activity. You can specify the condition as a numeric constant or a percentage of addressees.

    For example, if you wanted to require a 25-percent majority, you would specify an approver condition of 25%, as shown below.

    Alternatively, if you wanted to require approvals from two of the addressees, you would set the approver condition to 2.

    NOTE:When quorum support is enabled for an activity, you cannot specify retry settings for the activity. Therefore, the Retry Escalation Reminder Email, Retry Attempts, Retry Interval, and Retry Addressee fields are not displayed.

    Addressee Expression

    Specifies a dynamic expression that identifies the addressee for the activity. The addressee is determined at runtime, based on how the expression is evaluated.

    The first term of an addressee expression can be any of the following values:

    • Initiator

    • Recipient

    • Addressee of activity-name

    A separate Addressee of activity-name term is listed in the Expression drop-down list for each activity in the workflow (except the activity you are currently configuring). The activity-name is the display label you specified for the activity, or the default name, if you did not specify a display label.

    The second term of an addressee expression can be either of the following values:

    • Manager

    • <No attribute>

    The Manager attribute is available automatically because it has been previously defined on the User entity in the abstraction layer. Other attributes (in addition to Manager) are available for selection if they meet the following requirements:

    • Must be defined on the User entity in the abstraction layer

    • Must be single-valued

    • Must have a DN data type

    Addressee DN

    Specifies the distinguished name for a user, group, or task group.

    NOTE:If you want Task Group Managers to be able to search for tasks by task group (in the My Team Tasks action in the User Application), you need to specify the task group as the addressee.

    Timeout

    Specifies the period of time allotted for the activity to complete its processing. The timeout interval is the total time allowed for the activity, not the time allowed for each retry.

    The Timeout setting for the activity takes precedence over the Retry Attempts and Retry Interval values. Therefore, if the Timeout setting for the activity is reached before one or more of the retries have been attempted, the activity finishes processing without executing these retries. For example, if you set the timeout to 10 minutes, and define three retries with a retry interval of 5 minutes, the activity will finish after 10 minutes without attempting all of the retries. In this example, the second retry will be canceled. At the conclusion of the activity, the workflow engine will follow the link defined by the final timeout action in Designer.

    Specify a value in milliseconds, seconds, minutes, hours, or days.

    Retry Escalation Reminder Email

    Specifies whether e-mail messages should be sent to remind the current addressee of the activity that an action is required. Check this box to enable this feature.

    To change the retry escalation reminder notification settings for this activity, click the Edit this activity’s retry reminder email icon to configure escalation reminder notifications. Specify these settings:

    • Start specifies when to send the first reminder. The start value is an offset from the time of the retry assignment.

    • Interval specifies how often to send reminders after the first reminder has been sent.

    • Email Template specifies the language-independent name for the template to use for reminder e-mail messages. After the template name has been specified, the notification engine can determine which language-specific template to use at runtime.

      The language-independent template can have any name you like. The default template for reminder e-mail messages is called:

      Provisioning Reminder

      Each language-specific version of a template must have a suffix that provides a language code (for example, _fr for French, _es for Spanish, and so forth).

    Retry Attempts

    Specifies the number of times to retry the activity in the event that the retry interval has been reached.

    When an activity reaches the retry interval, the workflow process tries to complete the activity again, depending on the retry count specified for the activity. With each retry, the workflow process can escalate the activity 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 is executed, the activity might be marked as approved or denied, depending on how the workflow was configured.

    The Timeout setting for the activity takes precedence over the Retry Attempts and Retry Interval values. Therefore, if the Timeout setting for the activity is reached before one or more of the retries have been attempted, the activity finishes processing without executing these retries. For example, if you set the timeout to 10 minutes, and define three retries with a retry interval of 5 minutes, the activity will finish after 10 minutes without attempting all of the retries. In this example, the second retry will be canceled. At the conclusion of the activity, the workflow engine will follow the link defined by the final timeout action in Designer.

    Retry Interval

    Defines the period of time allotted for the addressee to complete the task. When the Retry Interval is reached, the workflow can optionally reassign the activity to a new addressee or try again with the original addressee. The Addressee Expression gives you control over the reassignment.

    Retry Addressee Expression

    Specifies a dynamic expression that identifies the user who should get this task in the event that the timeout limit has been reached.

    The retry addressee is determined at runtime, based on how the expression is evaluated.

    The first term of an addressee expression can be any of the following values:

    • Initiator

    • Recipient

    • Addressee of activity-name

    A separate Addressee of activity-name term is listed in the Expression drop-down for each activity in the workflow (including the activity you are currently configuring). The activity-name is the display label you specified for the activity, or the default name, if you did not specify a display label.

    The second term of an addressee expression depends on how the data abstraction layer has been defined. For example, you might see the following values:

    • Manager

    • Group

    • Direct Reports

    • <No attribute>

    If you select Manager, each retry will escalate to a new manager at a higher level within the organization. Therefore, be sure to set the retry count to a number that is suitable for your organization. In any case, the retry count should not exceed the number of levels of management above the current addressee.

    Retry Addressee DN

    Specifies the distinguished name for a user or group that should get this task in the event that the retry limit has been reached.

  6. When you finish configuring an activity, you might need to scroll down to see the other activities for the flow.

  7. Click Next.

NOTE:The number of activities you can configure varies, depending on which provisioning request definition was used as the basis for creating this definition. The number and type of entitlement parameters varies, depending on the provisioned resource associated with the request.

Specifying the Access Rights for the Provisioning Request

To specify the access rights for a provisioning request:

  1. To add a user, group, or other eDirectory™ object to the list of trustees for this request definition, click Add, then select the object.

    After you have added an object, it is included in the list of trustees.

  2. To remove a user, group, or other object, select the item in the Trustee list, then click Remove.

  3. Click Next.

Specifying the Initial Status of the Provisioning Request

To set the initial status of the provisioning request:

  1. Click the button for the desired status:

    Status

    Description

    Active

    Available for use.

    Inactive

    Temporarily unavailable for use. This is the default.

    Retired

    Permanently disabled.

  2. Click the button for the correct action (Grant or Revoke).

  3. Click Next.

17.3.3 Deleting a Provisioning Request

To delete a provisioning request:

  1. Select the provisioning request you want to delete by clicking the check box next to the name.

    You are not permitted to delete a provisioning request that is a template.

  2. Click the Delete command in the Provisioning Request Configuration panel.

17.3.4 Filtering the List of Requests

To filter the list of requests:

  1. Click the Actions command in the Provisioning Request Configuration panel.

  2. Click the Define a Filter command on the Actions menu.

    Specify the filter characteristics:

    Choice

    Description

    Turn off filtering

    Disables any existing filtering for the list.

    Filter for status equals

    Filters based on the status. You can filter the list based on any of the following status codes:

    • Active
    • Inactive
    • Template
    • Retired

    Filter for category equals

    Filters based on category. Select any of the defined categories.

    Filter for description contains

    Allows you to search for text in the request description. Type the string you want to search for.

17.3.5 Changing the Status of an Existing Provisioning Request

To change the status of an existing provisioning request:

  1. Select the provisioning request for which you want to change status by clicking the check box beside the name.

  2. Click the Actions command in the Provisioning Request Configuration panel.

  3. Click the Change Status command on the Actions menu.

  4. Click the status in the Status menu:

    Status

    Description

    Active

    Available for use.

    Inactive

    Temporarily unavailable for use.

    Retired

    Permanently disabled.

  5. Click the button for the correct action (Grant or Revoke).

  6. Click Finish.

17.3.6 Defining Rights on an Existing Provisioning Request

To define rights on an existing provisioning request:

  1. Select the provisioning request for which you want to define rights by clicking the check box beside the name.

  2. Click the Actions command in the Provisioning Request Configuration panel.

  3. Click the Define Rights command on the Actions menu.

  4. Follow the steps described in Specifying the Access Rights for the Provisioning Request.

To define rights on a provisioning request with iManager:

  1. Select the provisioning request for which you want to define rights by clicking the check box beside the name.

  2. Click the Actions command in the Provisioning Request Configuration panel.

  3. Click the Define Rights with iManager command on the Actions menu.