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.
The Identity Platform honors the rules from top to bottom, and you can drag and drop rules to organize them.
Setting up authentication rules
With a policy open in edit mode, select the Authentication Rules tab.
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.
Redirect to. When a user logs in, redirect users to another URL.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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"
After you add and reorganize the authentication rules, Save your changes.