Scenarios and conditions

Scenarios enable you to configure different authentication requirements for a specific set of context conditions. A scenario is always defined within a policy, and it modifies the access requirements of that policy when the specified context conditions are met.

Each scenario includes the following:

Conditions that define the context of an access attempt.
Decision that specifies whether access is granted or denied under the specified conditions, identifies the authentication methods that are required, 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.

Conditions

A scenario can include conditions to define the context of an access attempt.

The effect of conditions is that STA first determines which policy applies, based on scope matching.

Next, within the policy, STA searches for the first scenario for which the context conditions are matched. As with policies, scenarios are ranked for condition matching evaluation.

If multiple conditions are configured in a scenario, then all of the scenario conditions must be met in the context of a given access attempt for the scenario to apply in that access attempt.

When STA matches a policy's scenario to an access request, STA applies the scenario's authentication requirements. If none of the scenarios match the access request, STA applies the policy's default authentication requirements.

Network condition

The network condition checks whether the access attempt originates inside or outside the specified networks. You specify the IP addresses or IP address ranges to check. This is different from restricting logins to a specific IP range.

alt_text

The network condition includes the following options:

Inside these networks: Checks whether the access request originates from an IP address that is included in the network.
Outside these networks: Checks whether the access request originates from an IP address that is not included in the network.

When you add this condition, enter each IP address or IP address range on a new line in the text box, and use these formats:

Single IP address: 1.1.1.1
Range of IP addresses: 1.1.1.1-1.1.1.255

Anonymizer condition

The anonymizer condition checks whether the access request originates from behind an anonymizer (such as VPN, proxy, or Tor) that hides the originator’s real IP address. This condition uses a regularly updated IP intelligence database that keeps track of anonymizers in the public network.

Anonymizer condition

Known user device condition

This condition checks whether the access attempt originates from a device that is known for this user. It determines whether this user has successfully authenticated using this device in the specified period.

alt_text

When you select the Known User Device condition, you enter the number of days to check.

Domain-authenticated user device condition

The domain-authenticated user device condition checks whether the user authenticated with the same device to the Windows domain in the specified period. STA determines whether a valid Kerberos ticket (valid for the user on the device) is present on the device or was detected within the specified period.

To add this condition, Integrated Windows Authentication (Kerberos) must be enabled.

alt_text

The domain-authenticated user device condition includes the following options:

The user successfully authenticated: The condition is met if the user successfully authenticated to the domain with the device in the specified number of days.
The user did not authenticate: The condition is met if the user has not authenticated to the domain with the device within the specified number of days.

When you add this condition, enter the number of days that apply to the selected option.

Operating system condition

The operating system (OS) condition checks whether the operating system is included in the list of operating systems and versions. This condition allows you to configure the policy behavior for cases where your IT group either supports or does not support the operating system.

OS conditions

When you specify the operating systems (OS) and versions, you can use either a blocklist or allowlist approach:

Listed below: (allowlist) The condition is met if the operating system is included in the list.
Not listed below: (blocklist) The condition is met if the operating systems is not included in the list.

When you add an OS condition, you select the operating systems and versions to check for.

If you select Listed below, Any version is selected by default. Any version includes every existing version of the operating system, including versions that are not listed.

With the Firefox browser, the following occur due to the limitations of the browser:

- Windows 11 is detected as Windows 10.

- iPadOS 15 and iPadOS 14 are detected as iPadOS 13.

- macOS 12 and macOS 11 are detected as macOS 10.15.

With the Safari browser, the following occurs due to the limitations of the browser:

- macOS 12 and macOS 11 are detected as macOS 10.15.

User location condition

The user location condition checks whether the access attempt originates from any of the specified countries.

User location condition

When you add a user location condition, you enter the country names in the text box.

You can use either a blocklist or an allowlist approach.

From these Countries: (Whitelist) The condition is met if the country is in the list.
Not from these Countries: (Blacklist) The condition is met if the country is not in the list.

The user location condition is evaluated based on the country that maps to the IP address, even if it belongs to an anonymizer.

Country change condition

The country change condition checks whether the access attempt originates from a different country compared to the previous successful access by the same user.

If access is initiated through a VPN, the system generally considers the country location to be undefined and does not identify a country change.

This condition is always evaluated based on the country that maps to the IP addresses, even if it belongs to an anonymizer.

Country change condition

When you add the country change condition, you select whether access is Granted or Denied when the scenario conditions and access requirements are met.

Conditions and subscription plans

Some conditions are available only with higher-level subscription plans.

Condition	Subscription plan
Network	All
Anonymizer	STA and STA Premium
Known User Device	STA and STA Premium
Domain-Authenticated User Device	STA and STA Premium
Operating System	STA and STA Premium
User Location	STA and STA Premium
Country Change	STA and STA Premium

Combining conditions

You can combine conditions using AND/OR logic. To use AND logic, create one scenario with multiple conditions. To use OR logic, create a separate scenario for each condition.

Example: Network AND Anonymized: To deny access to any request made from an anonymized network, except those you explicitly consider as legitimate, create one scenario that enables both the Network – Outside theses networks and Anonymized conditions.
Example: User Location AND Domain-Authenticated User Device: To relax authentication requirements when the user requests access from a specified country on a domain-authenticated device, create one scenario that enables both the User Location and Domain-Authenticated User Device conditions.
Example: Country Change OR Operating System: To increase authentication requirements if a Country Change occurs or if the Operating System on the device is not Windows 10, create a scenario for each condition.

Add a scenario

On the STA Access Management console, select the Policies tab, add a scenario using either of the following options:
- On the policy, select the menu and then select Add Scenario.
- Select a policy and then select + Add Scenario under the policy.
In the New Scenario field, enter a name.
Select a condition check box and display the options for that condition.
Under Decision, select whether access is Granted or Denied.

If you select Granted, select the credentials that users must authenticate with:
- 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.
Select how often users must provide their credentials:
- 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.
Click Save.