Access policies

Use policies to define the requirements that must be met by a user to access an application. For every access attempt, STA applies and enforces the authentication requirements of the applicable 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).

There are two types of access policies:

• Exception policies: An exception policy applies to specific groups of users 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. The scope of an exception policy includes specific groups or applications.

  

• Global policy: There is only one global policy and it applies to all groups of users and applications. An account must have a global policy. The global policy is the default or fallback policy that is evaluated only if no exception policies match the scope of the access request.

  

What's in an access policy

Each access policy is a combination of:

• Scope: The scope of a policy is the combination of user groups and applications to which a policy applies.

  • Groups: Members of a department or organizational structure as defined in STA or as defined in the organization’s directory and synchronized by the SafeNet Synchronization Agent.

  • Applications: Cloud software and services that use STA for access management. They are listed on the Applications tab.

    Windows Logon should not be part of any application policy in the STA console.

    

• Decision: Each policy includes a decision about whether access is granted or denied. If access is granted, the policy also specifies which authentication methods are required and how often users must authenticate.

• Scenario (optional):

  • Conditions: Define the context of an access attempt, including the user's IP address, operating system, location, and more.

  • Decision: Specifies whether access is granted or denied. If access is granted, it includes the authentication method that is used and indicates how often users must authenticate.

  When STA matches a policy's scenario to an access request, STA applies the scenario's decision. If none of the scenarios match the access request, STA applies the policy's default decision. Learn more about how policies are ranked and evaluated.

How access policies and scenarios are evaluated

For any access request, only one policy applies. When STA determines which policy applies, it is this policy that fully governs the access requirements for that request.

If for a given access request, the applicable policy includes one or more scenarios, STA tries to match the conditions of the scenarios. The first scenario that has its conditions matched fully governs the access requirement for that access attempt.

The maximum number of policies per tenant (account or virtual server) is 50. The maximum number of scenarios per policy is 20.

STA determines which policy and which scenario applies independently for each access attempt, regardless of whether the access attempts are taking place in the same or different single sign-on (SSO) sessions.

The policies are evaluated, as follows:

• Exception policies and their scenarios are evaluated first, from highest to lowest ranking (1, 2, 3, etc.). The access requirements of the highest ranking policy and scenario that match the scope of the request are applied.

• If no exception policies match, the global policy is applied

Access policy examples

The following are conceptual examples of access policies with high, medium, and low security levels.

Example: High-security global policy

You can configure the global policy to provide high-security (password plus OTP every access attempt, or CBA every access attempt) in cases where you want to, by default, provide a high level of protection for applications.

The tradeoff for a high level of protection is that, unless an access request matches an exception policy with medium- or low-security, your users have to provide their password and OTP, or their certificate with every access attempt.

Example: Medium-low-security scenario – Location condition

You can add a scenario (for example, HQ) to the global policy to provide medium-low security (password once per session and OTP once/session, or CBA once per session) for groups of users that access applications from one or more specific locations (for example, the country with the account head office).

This scenario allows all users from a trusted location (for example, the country where the organization’s head office is located) to more easily access all applications, while users from all other countries have to meet the more rigorous access requirements of the global policy (password and OTP every access attempt).

Example: Medium-security exception policy

You can add an exception policy (for example, Clerical) to allow users who are members of specific groups to authenticate with medium-security credentials (such as password every access attempt and OTP once per session) when they access either specific or all applications.

In this example, access requests matching (Scope) Group 1 and App N must authenticate with their password every attempt and OTP once per session.

Each exception policy is assigned the rank of 1 when it is added to the list of policies. In addition, the rank of the other policies (if any) in the list are incremented by 1. Therefore, in this example, the global policy, formerly ranked 1, is now ranked 2.

Example: Medium-low-security scenario – Network condition

You could add a scenario (for example, Hi-speed) to allow specific groups of users from specific IP addresses to authenticate with low-security credentials (such as password and OTP once per session) when they access either specific or all applications.

In this example, access requests matching (Scope) Group 1 and App 1, and (Scenario) IPAddrN need only supply their password and OTP once/session.

Example: Low-security exception policy

You could add a low-security exception policy (for example, Executive) to allow specific groups of users to authenticate with low-security credentials (such as password once per session and, optionally, Integrated Windows Authentication) when they access either specific or all applications.

You would configure your network for low security in cases where you want to provide relatively easy access to the applications that are available on your network. The tradeoff for easy access by your users is that your applications would be relatively vulnerable to unauthorized access.