The policies management console allows you to review the list of existing policies, update, delete, or create new ones.
Navigate to Policies > Standard from the side menu to see the list of pre-defined standard policies. Standard policies are either pre-defined by Acceptto or the customer's administrators. On this page you only can do the following operations:
- Specify the target applications
- Enable or disable the policy
- Provide the parameters for the policy
In order to create or update policies navigate to Policies > Advanced from the side menu. On this page, you can create, update or delete policies in addition to the available options in Standard mode. Administrators can use this mode to create new pre-defined policies so that they appear in the Standard mode.
You can delete a policy by clicking on and approving the confirmation.
Clicking on will take you to the edit mode of Policy Details Page where you can update the selected 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.
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 the user logs in to an application via SAML, as well as continuous authentication, such as when the user switches between SAML applications while already logged in to the SAML Idp.
- Enrollment When the user is logging in for the first time
- Applications Which SAML applications this policy should apply to; alternately, check Apply to All Applications for universal coverage
- Enabled Whether this policy is currently active
AdvancedWhen checked, the policy will appear on the standard policies page
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.
Below you can find the list of condition predicates.
The policy will be applied in all circumstances for the specified application(s) and event. For example, you want to disable MFA for all users temporarily.
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 the specified groups.
Read more about LOA score.
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 log in 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.
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, combined with the Country condition, 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.
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 example, you can define a policy that auto approves a user's request to authenticate to a web application if the same user has MFA'd into their Windows machine from the same IP address within the last 5 minutes.
Allows you to define a condition based on whether the user has a paired workstation with the specified configuration; all selected fields must match in order for the condition to be met. This allows granular control of when to apply a policy. Configuration options include operating system type and version, whether the device is configured to use a firewall, password, or secure boot, IP address, and more.
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 User-Defined Policy Predicate page to learn more.
When all 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 to tune the LOA score based on your needs
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.
In cases where there are multiple policies applied to the same transaction, the result is calculated according to the following order:
- If there is one or more matching policy with Automatically Reject action, the MFA gets rejected
- If the above rule is not true and there is one or more matching policy with Force Out of Band action, then the user gets MFA
- If the above rules are not true and there is one or more matching policy with Automatically Approve action, then MFA gets approved
For example, if five different policies match the current conditions and one of them is set to execute "Automatically Reject" action, then the user will be rejected no matter what action is specified for the other policies.