Skip to main content

Policy configuration - Authentication rules

On the Authentication rules tab in a policy, you can choose how to handle login for users. You can require multi-factor authentication (MFA), skip MFA, use Windows SSO, block users, or redirect them.

Use case scenario

You have executives who work for ACME Corporation. ACME has offices all over the world and a small group of executives who travel extensively. You need an authentication policy to:

  • Bypass MFA for executives who are members of the ACME_executives group, and are a low risk based on behavior and IP reputation.

  • Block user login attempts from China, except for the group of executives working out of the Beijing office.

The following is an overview of how to set this up:

  • Rule 1: Skip MFA if the user is in ACME_executives group AND is a low user risk.

  • Rule 2: Block if the user is located in China AND is not in the ACME_executives group.

  • Else Rule: The last catch-all rule. This rule cannot be deleted. You can set it to Prompt for MFA, Skip MFA, or Run Device/Browser recognition.

    policy_overview_001_2202.png

The Identity Platform honors the rules from top to bottom, and you can drag and drop rules to organize them.

Setting up authentication rules

  1. With a policy open in edit mode, select the Authentication Rules tab.

  2. When adding or editing a rule, you can apply these conditions:

    • Prompt for MFA. When a user logs in, they must provide authentication.

    • Skip MFA. When a user logs in, allow access.

    • Block. When a user logs in, block access.

    • Run Windows SSO. When a user logs in, verify their user credentials through Windows SSO. You can use this as a condition in rules for Country, IP Range, or Threat Service.

      Note

      To use this condition, enable Allow Windows SSO integration in the Active Directory or Microsoft Entra ID (formerly Azure AD) data store configuration.

      For more information about Windows SSO integration, see:

      You can only have one "Run Windows SSO" conditional rule in a policy.

    • Redirect to. When a user logs in, redirect users to another URL.

    • Continue to next rule. This rule is for the Risk Engine in its learning phase. It will move on to the next rule in the authentication policy without applying any MFA action. Use this to allow the Risk Engine to gather data.

  3. You can organize the rules in these ways:

    • To move a rule, click and hold the 10-dot vertical icon on the left to drag and drop a rule and change its hierarchy in the list.

    • To remove a rule or condition, click the minus icon or the trash can icon.

    • To change the properties of a rule, click the blue rule link.

  4. To add a new rule, click Add New Rule and choose from the following rule types:

    Dynamic IP Blocking

    Rule to block source IP address from password spraying and other online password attacks.

    For example, instead of locking user accounts, the Identity Platform blocks login attempts coming from the source IP address.

    Note

    To change how long the Identity Platform blocks the source IP address after a specified number of failed logins, go to IP Filtering in the left navigation of the Identity Platform.

    Take note that the Identity Platform applies this change to all policies that use the Dynamic IP Blocking rule.

    In the Set IP Addresses field, add trusted IP addresses for this policy. The Identity Platform will not block trusted IP addresses if it reaches the maximum number of failed login attempts.

    adaptive_auth_rules_001_2104.png

    Dynamic Perimeter

    Access is determined by the user's login distance from the previous location.

    For example, if the user login is over 60 miles away from the last login, they will be asked for a form of MFA.

    adaptive_auth_rules_002_2104.png

    Country

    The rule determines access based on the user's login country.

    For example, if the user login is in the United States, then the user can skip MFA.

    adaptive_auth_rules_003_2104.png

    Geo-velocity

    The rule decides access based on how fast you traveled between your previous and current login.

    For example, if the user logged in from Los Angeles (point A) at 11:15 a.m. and then from New York (point B) at 11:45 a.m. on the same day, they are asked to provide a form of MFA.

    adaptive_auth_rules_004_2104.png

    Group

    Rule determines access based on group membership.

    For example, if the user belongs a specific group, they can skip MFA.

    Note

    Before you can use this rule, groups must be defined in the data store for your organization.

    adaptive_auth_rules_005_2104.png

    IP Range

    Rule determines access based on IP ranges. You can enter IPv4 addresses as individual values, ranges, or using CIDR Notation.

    For example, if the user login is from one of the specified IP addresses, you can choose what action to take. You can ask the user for a form of MFA, skip MFA, block the user, or redirect them to a different URL.

    adaptive_auth_rules_006_2104.png

    Threat Service

    Access is determined based on known risks associated with the login attempt. The SecureAuth Threat Service analyzes IP traffic for threats.

    For example, if the user login is connected to a known threat, they must provide a form of MFA.

    Note

    You must have a license to use this feature. To learn more about the Threat Service rule, contact your SecureAuth Account Manager.

    adaptive_auth_rules_007_2104.png

    User

    Rule determines access based on whether the user login matches the specified user ID.

    For example, if the user login matches the user ID, they can skip MFA.

    adaptive_auth_rules_008_2104.png

    User Risk

    Access is determined based on user reputation and behavior factors during login. User risk is a learning algorithm of user behavior over time.

    For example, if the user's login reputation and behavior is a high risk,they must provide a form of MFA.

    Note

    You must have a license to use this feature. To learn more about the User Risk rule, contact your SecureAuth Account Manager.

    adaptive_auth_rules_009_2104.png

    To learn more about configuring user risk scores, see SecureAuth User Risk settings.

    Level of Assurance (LOA)

    Access is determined based on LOA confidence score of the user during login. LOA confidence score quantifies how confident the user is the identity they claim to be.

    For example, If the user has a specific LOA level, you can increase friction by asking them for a form of MFA.

    Note

    You must have a license to use this feature. To learn more about the Level of Assurance (LOA) rule, contact your SecureAuth Account Manager.

    adaptive_auth_rules_011_2403.png

    To learn more about configuring LOA scores, see SecureAuth Level of Assurance (LOA) Provider settings.

    All other logins

    This is a catch-all rule evaluated last and determines access (Prompt MFA or Skip MFA) if it doesn't trigger any of the above rules. You cannot delete or reorder this rule in the list.

    The Run Device/Browser Recognition option runs device/browser recognition and applies one of the following conditions:

    • Skip MFA when the device or browser profile matches the user profile

    • Prompt for MFA when the device or browser profile do not match

    • Prompt for MFA when device recognition is not enabled

    • Prompt for MFA when the Login workflow includes "Valid Persistent Token"

    adaptive_auth_rules_010_2202.png
  5. After you add and reorganize the authentication rules, Save your changes.