An exception policy applies to specific user groups and applications. Exception policies are optional. An account can have one or more exception policies. If present, exception policies are evaluated before the global policy.

Access policies apply strictly to traffic from applications that are configured on the STA Access Management console, on the Applications tab. Access policies do not apply to traffic that comes through the authentication nodes that are configured on the STA Token Management console (including RADIUS).

1. On the STA Access Management console, select the Policies tab and then select the Add Policy icon.

   

2. Enter a policy name in the New Policy box.

3. Enter a brief description in the New Policy Description box.

4. Under Scope, in the Users section, select one of the following options:

   • All Users

   • Any of these User Groups and then enter the affected user groups.

5. In the Applications section, select one of the following options:

   • All Applications

   • Any of these Applications and then enter the affected applications.

6. In the Decision section, select either Granted or Denied.

7. Select the Authentication methods with which all users must authenticate:

   • Password: Require users to authenticate with their domain password at specified times.

     To use the domain password, you must use the SafeNet Synchronization Agent to synchronize the domain password from Active Directory (AD) with the STA server.

     If you use password authentication, you can also select the following option:

     • Allow Integrated Windows Authentication (Kerberos): When you select this option, STA accepts the Kerberos ticket that was acquired when the user logged in to their current Windows session. Users do not have to re-enter their password each time they access an application that is secured by STA access policies. However, the user might still be prompted for an OTP if the policy requires it.

       This option is available only if integrated Windows authentication is configured on the Settings tab. It also requires that the AD and STA establish a trust relationship.

   • OTP: Require users to authenticate with a one-time password (OTP) at specified times.

   • Password and OTP: When both a password and an OTP are required for authentication, STA prompts the user for the password first.

   • FIDO: Users must log in with their built-in authenticator or security key, such as Windows Hello for Business and FIDO2 authenticators. FIDO cannot be used in combination with an OTP or with CBA. This option is available only if FIDO authentication is enabled on the Settings tab.

   • Certificate-based authentication (CBA): Users authenticate with a software or hardware certificate, such as a smart card, that is issued by a certificate authority (CA). This option is available only if at least one issuing CA is configured on the Settings tab.

     This feature is available with the STA Premium subscription plan only.

   • External IDP: STA orchestrates the use of secondary, external IDPs, such as SAS PCE or Microsoft Entra ID. Each external IDP can be either the only authentication method or the second factor of authentication. It cannot be the first factor in multi-factor authentication.

     IDP orchestration is available with the STA and STA Premium subscription plans.

8. Select how often users must authenticate:

   • Once per session: Prompt the user to authenticate once per STA SSO session within a browser.

   • If not verified in the last [number of minutes or hours]: Prompt the user to authenticate at least every N minutes or hours. Select the value that meets your organization's requirements. The values supported by STA are: 5, 10, 15, 30, 45, or 60 minutes; as well as 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, or 12 hours.

     Use this option to provide a presence check for sensitive applications by requiring users to re-authenticate if the specified number of minutes or hours have elapsed since they last accessed the application.

     Between this setting and the single sign-on session timeout, the shortest setting takes precedence.

   • Every access attempt: Prompt the user to authenticate regardless of whether they previously authenticated in the current STA SSO session.

     If you use CBA, some certificates and their drivers might have their own session, apart from the STA SSO session, and might not prompt a user for authentication. For example, the user might not be prompted to authenticate as long as a smart card is inserted in a computer.

9. Click Save to save your changes.

10. (Optional) Add a scenario.

Change the rank of exception policies

STA assesses any exception policies before it assesses the global policy.

In addition, by default:

• Among the exception policies, the most recently added policy or scenario assumes the top priority.

• Within the global policy, the most recently added scenario assumes the top priority.

The global policy is always the lowest ranking policy. However, you can change the rank of the exception policies.

A conceptual view of the components that comprise exception and global policies follows.

The ranking of the exception policies determines the order in which the scope matching evaluation is done.

The global policy cannot be moved up in a list of policies. It is always the lowest ranking policy and serves as the default or fallback policy.

1. On the STA Access Management console, select the Policies tab.

2. Change the rank using either the policy menu or by dragging and dropping the policies:

   Clerical as policy #2	Moving the policy	Clerical as policy #1

   • To use the menu, select the menu on the exception policy and select Move Up or Move Down, as desired.

   • To drag and drop, click the rank number and drag the policy up or down the list, and then drop it in the desired location.