Automate token provisioning

One of the most powerful features of the server, provisioning rules determine under what conditions tokens are automatically issued and revoked. Combine provisioning rules with pre-authentication rules to seamlessly migrate users from static passwords to token authentication without service interruption and with little to no administration.

Rules are triggered when group memberships and other user attributes change. For example, if a user is added to a group that is included in a rule, SAS provisions the user with a token. Conversely, if a user is removed from a group included in the rule, SAS revokes the token.

Provisioning rules can be used with internal groups or with LDAP synchronized groups. By combining provisioning rules with LDAP synchronization or integration, the server can automatically issue and revoke tokens based on changes made in LDAP without the intervention of an operator.

Users in these groups must have an email address or a mobile/SMS number (depending on the token type). Otherwise, SAS cannot auto-provision them with a token.

Add a provisioning rule

1. On the SAS console, select Policy > Automation Policies > Provisioning Rules.

2. Click New Rule.

   

3. Configure the provisioning rule options:

   • Rule Name—This is a unique, descriptive name for the rule.

   • Token Type—This is the type of token to be provisioned when the rule evaluates true.

   • Issue Duplicate Types—If unchecked, a user is not provisioned with the selected token type if they already have one of the same type, as a result of being manually assigned a token or a different provisioning rule.

   • Auto Revoke—If checked, the token issued by this rule is revoked if the rule evaluates false for the user, such as when a user is removed from the monitored groups.

     Select this option only when a user remains synced to SAS but the provisioning rule no longer applies. If a user is removed from SAS (for example because they are no longer part of a sync group) all of their tokens are revoked regardless of whether Auto Revoke is selected.

   • Notify Users With Active Provisioning Revoke—If checked, users are notified if their auto-provisioned tokens are revoked by the provisioning rule.

   • Container—The user must reside in the selected container for the rule to evaluate true.

   • Require Expiring—Select this option to provision a replacement token N days before the expiration date of any assigned tokens. If you also select Auto Revoke, then the replaced token is revoked after the user enrolls the replacement token.

   • Require In-Service Expiry—This option is used to replace tokens that have been in the field for an extended period of time and are likely to need battery replacement. Enable this option to provision a replacement token for any assigned tokens that has been in use for more than N years. Enabling Auto Revoke results in the replaced token being revoked immediately upon the user completing enrollment of the replacement token.

   • Target Groups—The groups to which the rule applies.

   • Affected Group Members

     • Users that belong to ANY of the target groups. (OR Logic. Highly Recommended.)

       If one or more groups are selected for a rule, users that belong to any of the selected groups will be included in the rule.

     • Users that belong to ALL of the target groups. (AND Logic. Use with Caution.)

       

       If multiple groups are selected for a rule, only the users that belong to all of the selected groups will be included in the rule. For example, if GroupA, GroupB, and GroupC are selected, only users that belong to GroupA, AND GroupB, AND GroupC will be included in the rule.

Affected group members

Consider the case where you create provisioning rule One for Group A. Initially, the rule applies to all users in that group. However, that may change if you add a group to the original rule, depending upon whether you apply OR logic or AND logic, as described in the scenarios that follow.

If you add a group to an existing provisioning rule, you may dramatically and unexpectedly change the effect of the rule. For example, if you add a group to an AND logic provisioning rule that has provisioned tokens and has Auto Revoke selected, then tokens are revoked from all users from the original groups that are not also members of the new group.

Scenario 1: Users that belong to ANY of the target groups. (OR logic. Highly recommended.)

If you select Users that belong to ANY of the target groups and apply rule One to Group B (that is, add Group B to rule One) the rule applies to ALL users from Group A and Group B, as shown in the following table:

Scenario 2: Users that belong to ALL of the target groups. (AND logic. Use with caution.)

If you select Users that belong to ALL of the target groups and apply rule One to Group B (add Group B to rule One), the rule applies to only the users who belong to both Group A AND Group B, as shown in the following table (that is, Betty and Fred).

Apply provisioning rules to nested groups

Auto-provisioning can be enabled for users in nested groups. When enabled, provisioning rules for a parent group are applied to all of its nested groups in SAS, and all users that are in the nested groups receive an email for token activation. This policy applies to user and role provisioning.

1. On the SAS console, select Policy > Automation Policies > Provisioning Policy.

   

2. Select Provisioning Rules will use nested group relations.

Self-Enrollment Policy

Use this policy to control self-enrollment thresholds and alerts.

• Self-Enrollment base URL—This is the URL to which the user will be directed as a result of a provisioning task and is included in the enrollment email instructions to the user. Do not modify this value unless you have installed a stand-alone enrollment web server.
  • To enforce self-service over SSL, replace http with https in the Self-Enrollment Base URL field. Do not modify this value unless you have installed a stand-alone enrollment web server and have a valid certificate installed.
• Activation Code Format—This option determines the strength of the activation code included in the enrollment message and encoded in the enrollment URL. Options are numeric, alphabetic or alphanumeric formats.
• Reservation time to live—This is the maximum number of days the user has to complete enrollment commencing with the start date of the provisioning task. This value is added to the provisioning task start date to generate the provisioning task stop date. If set to 0, a provisioning task will never expire. The default value is 10 days.
• Enrollment lockout after—This value determines the number of failed enrollment attempts by a user. When this threshold is exceeded, the user will be unable to enroll their token.
• Days Before Expiry to Warn— This value allows you to send a provisioning reminder via email to the user a specified number of days (0-31) before expiration of their provisioning task. The default setting is 0, which will not send a reminder. You can modify the email message template called EnrollmentExpiring to customize the content of the expiry reminder email sent to the user.
• Enable Multi-Device Instructions—If checked, the Multi-Device Instructions section in Self-Service > Configure Self-Enrollment Pages is enabled in the self-enrollment policy for MobilePASS tokens. Multi-Device Instructions may be useful to:
  • Provide assistance to users when the device where the page is loaded is not a selected allowed target. Allowed Targets Settings are designed to allow the user to choose the instructions that are related to their chosen device type and selected in Policy > Token Policies.
  • Provide instructions to users who may be loading the Self-Enrollment page on a device that is not their intended device for enrolling the token (and wish to only review the instructions).
• Display QR Code—If checked, the enrollment email sent to the user will include the link to the page on the SAS Self-Service module where the QR code is displayed.
  • The QR code will display only if a supported device is selected in the device selection drop down menu of the enrollment email.

Auto remove

Auto remove is used to automatically remove reports that are no longer required, based on their age. Any report older than the configured number of days is removed from the Virtual Servers > Reports > My Report Output module.

The source data is retained and the reports can be re-generated.

To configure the automatic removal of reports:

1. Click Virtual Servers > Policy > Automation Policies > Auto Remove.
2. Enter the number of days, after which the reports should be removed, in the field provided. Some key values include:
3. 1—(Minimum) Removes reports that are more than one day old.
4. 365—(Default) Removes reports that are more than one year old.
5. 1826—(Maximum) Removes reports that are more than five years old.

In the SAS Classic service zone, reports that are more than one year old are removed even if the value in this field exceeds 365 (days).