Here you'll learn how to see the list of existing policies, update and delete them and create new policies.
You might not have access to all features listed here depending on your plan. Please contact us if you need to upgrade to enable specific features.
Policies Main Page
Navigate to Policies from the side menu to see the list of existing policies.
Deleting a Policy
You can delete a policy by clicking on and approving the confirmation.
Editing a Policy
Clicking on will take you to the edit mode of Policy Details Page in which you can update the selected policy.
Creating a New Policy
To create a new policy click on Create New Policy at the bottom of the table. You will be taken to the Policy Details Page with which you can define a new policy.
Policy Details Page
You can create a new policy or view and update an existing one from this page.
You specify the general policy information in this section:
- Name Policy name.
- Description Optional description for the policy.
- Event The event on which the policy will be evaluated. Available options:
- Authentication Both first-time authentication, such as when user logs in to an application via SAML, as well as continuous authentication, such as when user switches between SAML applications while already logged in to the SAML Idp.
- Enrollment When the user is logging in for the first time
- Enabled Whether this policy is currently active
- Applications Which SAML applications this policy should apply to; alternately, check Apply to All Applications for universal coverage
In this section you specify the conditions for which you would like the policy's action to be executed. The policy will be executed only when all condition predicates are met. In other words, the logic between the condition predicates is AND.
Here you can find the list of condition predicates:
This policy should be applied in all circumstances for the application(s) and event specified. For example you want to disable MFA for all user authentications temporarily.
Active Directory Groups
If integrated with your organization's Active Directory, you can specify one or more user groups so that the policy will be executed if the authenticating user belongs to any of them.
Overall LOA Score
LOA stands for Level of Assurance. It's a number between 1 and 4 that shows the level of assurance that the authenticating user is who they're claiming to be. The lower the LOA the higher the risk is. LOA score is calculated based on the information collected from each user from different sources such as AI/ML Engine, user browser fingerprint, geo-location networking information, etc.
You can specify the threshold for the LOA score to trigger the policy execution. You can set the policy to be executed either when the LOA score is greater than or equal to or smaller than or equal to a specific value.
For instance, if you set it to be greater than or equal to 3 and choose the Auto Approve action for the policy, the user will be allowed to login without multi-factor authentication.
Allows you to specify the condition based on the user's IP address. You can specify one or multiple IP addresses or a range of IPs using CIDR notation. They can be separated by commas, like
Allows you to specify the country where the user is located. This is based on the geo-location information obtained from the user's browser or mobile device.
If more than one country is specified, the condition is met when the user is located in any of them.
It’sMe Mobile App
You can specify conditions based on It'sMe mobile application such as the mobile operating system and the app version range.
Time of Day
Allows you to define the time and day pattern when the user is trying to authenticate. You can specify not only the time range but also the days of the week. For example, you can increase the friction for the users located in a specific country when they're trying to get access to the system while it's outside of business hours or during the weekend.
Login to Other Applications
Allows you to define a condition based on applications that the user has signed into within the specified period of time.
Selecting the Require matching IP address? option ensures that this condition is met only when the user is coming from the same IP address for each application.
For instance, you can define a policy that auto approves a user's request to authenticate to web application A if the same user has MFA'd into their Windows machine from the same IP address within the last 5 minutes.
This predicate gives you the highest level of customization. You can create a predicate using the Ruby programming language.
For example the following predicate UI:
Can also be written in Ruby in the admin panel console as a custom predicate:
Visit the code policy matcher page to learn more.
When all the policy conditions are met, the specified action for the policy will be executed.
Here are the actions you can select for Authentication events:
- Automatically Approve: Skips MFA by automatically approving the authentication
- Automatically Reject: Blocks user access by rejecting the authentication automatically
- Force Out Of Band: Overrides all current rules and forces the user to complete MFA
- Change LOA Score: Increase or decrease the user's LOA score so that you can tune the LOA score based on your needs
- Limit Out of Band Methods: Limits the selection of available out-of-band methods the user can use to complete MFA. You can choose multiple methods:
- Push Notification
- Voice Call
- Fido U2F
- Security Question
And the action you can define for Enrollment event:
- Require Device Pairing Forces the user to pair their mobile device when they're authenticating for the first time or if one is not currently paired.
The priority of the actions from the most important to the least is:
- Automatically Reject
- Force Out Of Band
- Automatically Approve
For example if the conditions for 5 policies are met and one of them is set to execute the "Automatically Reject" action, then the user will be rejected no matter what action is specified for the other policies.