Workflow Policy

Self-Service uses workflow policies to automate deployment of authenticators and to fulfill other requests from users, for example, on-demand authentication (ODA). Workflow policies determine how user requests are handled. They apply to the entire deployment. Each user request is governed by one workflow policy. The workflow policy includes:

  • General workflow settings

  • User and group settings

  • Hardware and software token request settings

  • On-demand tokencode request settings

  • The number of steps for each type of request

  • List of e-mail notification recipients for provisioning requests

  • The content of e-mail notifications for each type of request.

For more information about ODA and RBA, see On-Demand Authentication and Risk-Based Authentication.

Configure a Workflow Policy

When you install Authentication Manager with the provisioning feature of Self-Service, an initial workflow policy is automatically created. You can add more workflow policies, for example, if you want a workflow policy for hardware token distribution and another policy for on-demand tokencode service enablement.

Note: Do not use the characters (<) and (>) in e-mail templates.

Procedure

  1. In the Security Console, click Setup > Self-Service Settings.

  2. Under Provisioning, click Workflow Policies.

  3. On the Workflow Policies page, click Add New.

  4. On the Add Workflow Policy page, do the following:

    1. In the Workflow Policy Name field, enter a unique name that does not exceed 128 characters.

    2. (Optional) To make this policy the default policy for all new security domains created in this deployment, select Set as the default workflow policy.

    3. Under E-mail Notification Settings, select one or more of the following options:

      • Enable e-mail notifications for all workflow participants - All workflow participants (managers, or administrators with permission to approve requests or distribute tokens).

      • Enable e-mail notifications for Super Admin - All Super Admins.

      • Enable e-mail notifications for parent workflow participants - All approvers and distributors in the parent security domain of the user that made the request.

  5. (Optional) Under E-mail Notification Templates, customize the e-mails sent to Self-Service users when a request is submitted, waiting for approval, cancelled or rejected.

  6. Do one of the following:

    • To continue configuring this policy, click Save & Next.

      The User & User Group page displays.

    • To exit, click Save & Finish.

  7. On the User & Group page, do the following:

    1. Under Workflow Definitions, specify the number of steps required for each request type.

    2. (Optional) Under E-mail Notification Templates, customize the e-mail notifications that Self-Service sends to users about approvals.

  8. Do one of the following:

    • To continue configuring this policy, click Save & Next.

      The Hardware Token page displays.

    • To exit, click Save & Finish.

  9. On the Hardware Token page, do the following:

    1. Under Workflow Definitions, specify the number of steps required for each request type.

      Note: If ODA is configured as the identity confirmation method for risk-based authentication (RBA), RSA recommends that you set the approval level of the workflow definition to 0 for ODA. If this value is not 0 for ODA, users must request ODA and wait for approval before they can log on when RBA is enabled.

    2. (Optional) Under E-mail Notification Templates, customize the e-mail notifications that Self-Service sends to users about an approved hardware token and lost SID800 token.

  10. Do one of the following:

    • To continue configuring this policy, click Save & Next.

      The Software Token page displays.

    • To exit, click Save & Finish.

  11. On the Software Token page, do the following:

    1. Under Workflow Definitions, specify the number of steps required for each request type.

    2. (Optional) Under E-mail Notification Templates, customize the e-mail notifications that Self-Service sends to users about an approved software token.

  12. Do one of the following:

    • To continue configuring this policy, click Save & Next.

      The On-Demand Token page displays.

    • To exit, click Save & Finish.

  13. On the On-Demand Authentication page, do the following:

    1. Under Workflow Definitions, specify the number of steps required for On-Demand Authentication Enablement.

    2. (Optional) Under E-mail Notification Templates, customize the e-mail notifications that Self-Service sends to users about an approved request for On-Demand Authentication.

  14. Click Save.

    The Workflow Policies page displays.

Manage Workflow Policies

You can edit a workflow policy, duplicate a workflow policy, and delete a workflow policy.

Procedure

  1. In the Security Console, click Setup > Self-Service Settings.

  2. Under Provisioning, click Workflow Policies.

  3. Do the following:
    TaskDescriptionProcedure
    Edit a workflow policy

    You can edit a workflow policy to change information, such as the policy name, the number of steps or items for each type of request, who receives e-mail notifications about requests, and the content of e-mail notifications.

    You can set the following numbers of steps for each type of request:

    • Zero to four approval steps

    • Zero or one distribution step for token requests

    Note: Each approval step requires a unique Request Approver.

    1. Use the search fields to find the policy that you want to edit.

    2. Select the policy that you want to edit and click Edit from the context menu.

    3. Make any necessary changes to the policy.

    4. Click Save.

      If you have not saved your edits, you can click Reset to change the policy back to its original setting.

    Change the default workflow policy

    If your organization wants to change the number of Request Approvers in a workflow definition, who receives e-mail, or the content of the e-mails sent to workflow participants, you can change the default workflow policy for your organization as needed.

    Each deployment has a default workflow policy that is assigned to all new security domains. You can change the default policy. The default policy applies to all security domains that are configured to use the default policy.

    1. Use the search fields to find the policy you want to set as the default.

    2. From the search results, click the policy you want to set as the default and click Edit from the context menu.

    3. Under Workflow Policy Basics, select the Default Policy check box to designate the new policy as the default policy for the deployment.

    4. Click Save.

    Duplicate a workflow policyWhen you duplicate a workflow policy, you create a policy that is identical to the original. You can edit the policy to customize it. The new policy is not assigned to a security domain until you manually assign it.

    1. Use the search fields to find the policy that you want to duplicate.

    2. Select the policy that you want to duplicate and click Duplicate from the context menu.

    3. In the Workflow Policy Name field, enter a name for the policy, and make any other necessary changes to the new policy.

    4. Click Save.

    Delete a workflow policy

    When you delete a workflow policy, the policy is removed from the deployment and can no longer be assigned. If you delete a policy that is assigned to a security domain, the default policy is automatically assigned to the security domain.

    You cannot delete the default workflow policy. If you want to delete the default policy, you must first designate another policy as the default.

    1. Use the search fields to find the policy that you want to delete.

    2. Select the policy that you want to delete and click Delete from the context menu.

    3. Click OK.