How policies are used in the Identity Platform
Policies in the SecureAuth® Identity Platform allow you to define rules to authenticate and block your users to certain resources. A policy is a collection of authentication rules to assert a user identity in the login workflow:
User login attempt to access a resource.
Identity Platform connects to the data store.
Authentication policy rules to block or allow user.
User identity is asserted into a resource.
The Identity Platform comes with a default policy that you can modify, but not delete. You can create more than one policy with different rules for your resources. When you first create a new custom policy, it brings over the rules from the default policy.
Login workflow examples
Example 1: Let's say a user logs in from Los Angeles, California (point A) at 11:15 a.m. and then from New York, New York (point B) at 11:45 a.m. on the same day. Something might be off; the adaptive engine can determine whether it is possible for the user to get from point A to point B at the time of login.
Example 2: You can block users from a certain country, but only allow employees who work in that country to access your organization's resources.
Example 3: For the employees in your organization, you can set up a passwordless authentication workflow and allow only the use of push notifications from an authenticate app to access Office 365 applications.
Each section below contains an overview of each tab you configure in a policy.
Authentication Rules tab
Adaptive rules to specify how to handle user login attempts to access a resource.
Identity Platform honors the rules from top to bottom, and you can drag and drop rules to organize them. You can also add conditions within a rule.
For example, you want to block users from China, but only allow employees who work in China to access your organization's resources.
Rule 1: Skip MFA if the user is a member of a specified group AND if the User Risk level is low.
This uses the Rule=Group AND Condition=User Risk
Rule 2: Block if the user is in a specified country, AND is not a member of a specified group.
This uses the Rule=Country AND Condition=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.
 |
To learn more about each rule type, see Policy configuration - Authentication rules.
Login Workflow tab
Choose the login experience for end user logins.
For example, you can choose a Passwordless login, in which users can log in with a FIDO2 security key as an authenticator.
Or, if you choose login with a Username | MFA Method | Password with password suppression. The condition for the password suppression could be that users are required to receive and approve a login notification on their mobile device after entering their username on the login page.
 |
To learn more about login workflows, see Policy configuration - Login workflow.
Multi-Factor Methods tab
Select the types of MFA users can choose to authenticate into resources attached to this policy. If you don't see an MFA method enabled on this tab, go to Multi-Factor Methods in the left navigation to enable it.
For example, you can allow your users to authenticate using FIDO2-enabled devices, YubiKeys, and an authentication app. But for this policy, you don't want to allow users to authenticate using SMS text message, email, or any other methods, you can clear all those check boxes.
 |
To learn more about selecting multi-factor methods, see Policy configuration - Multi-factor methods.
Resources tab
Select or add resources to which this policy applies.
For example, resources might be Office 365 and Salesforce. The policy determines the login experience and authentication for end user access to Office 365 and Salesforce.
 |
To learn more about adding and managing resources, see Policy configuration - Resources.