About Okta sign-on policies

Okta sign-on policies can specify actions to take, such as allowing access, prompting for a challenge, and setting the time before prompting for another challenge. You can specify the order in which policies are executed and add any number of policies. If a policy in the list does not apply to the user trying to sign in, the system moves to the next policy.

You can specify any number of policies and the order in which they are executed. There is one required policy named Default. By definition, the default policy applies to all users.

In addition to the default policy, which you cannot delete, there is another policy named Legacy that is present only if you have already configured MFA. This policy reflects the MFA settings that were in place when you enabled your sign-on policy, and ensures that no changes in MFA behavior occur unless you modify your policy. If needed, you can delete it.

When a policy is evaluated, the conditions in the policy are combined with the conditions in the associated rules. Rules are applied when all these conditions are met.

Note: A policy with no rules cannot be applied.

Policies can contain multiple rules, and the order of the rules determines their behavior.

 

Configuring sign-on policies for RADIUS applications

If you create an Okta sign-on policy from the admin console under Security > Authentication > Sign On, it will not apply to a RADIUS application. Sign-on policies for RADIUS applications must always be configured as part of the RADIUS application setup instead. For more information, see Add sign-on policies for applications.


Okta policy evaluation

Okta amalgamates the conditions of a policy and the conditions of a rule to determine whether a policy is applied to a particular user. Policies generally consist of large elements that can be applied to many users, such as a minimum password length. Rules consist of conditions such as place and circumstance, like geographical location or whether the user is on or off a company network. A policy that contains no rules cannot be applied.

For example, if you create a policy which you assign to the group “Admins”, you would create conditions special to the needs of administrators. The policy might contain a minimum password length of 12 to restrict password hacking. An applied rule to the policy might be one that allows for a self-service unlock only under certain conditions. One condition might be whether a particular admin is off or on your company network.

Tips:

  • A policy that contains no rules cannot be successfully applied—a warning will indicate that no rules exist for this policy.
  • Ensure that any restrictive rules are placed at the top of the Priority list.
  • If “Everyone” were on top, special conditions would not apply and a policy evaluation would be unnecessary. If multiple rules are present and the conditions of the first rule are not satisfied, Okta skips this rule and evaluates the following one.

MFA factors and sign-on policies

The Prompt for Factor check-box is not active unless at least one factor has been chosen from the Multifactor page.

To access the page and choose one or more factors, navigate to Security > Multifactor.

Note: If a specific factor is specified in a policy, that factor cannot be removed until it is removed from all the policies that require it.

If MFA is enabled for your org, you are required to specify at least one factor. If a factor is not specified, an error message appears on the Multifactor page.


Related topics

Configure an Okta sign-on policy

About MFA enrollment policies

About password policies

About app sign-on policies

Configure an MFA enrollment policy

Configure an app sign-on policy

Configure a password policy