Okta sign-on policies

Policies are used by Okta to control rules and settings that govern, among other things, user session lifetime, whether multifactor authentication is required when logging in, what MFA factors may be employed, password complexity requirements, what types of self-service operations are permitted under various circumstances, and what Identity Provider to route users to. Policies have rules applied to them, which determine whether they're applicable to a particular user at a particular time. Policies generally consist of large elements that can be applied to many users, such as a minimum password length. Rules, like policies, contain conditions that must be satisfied for the rule to be applied. They consist of conditions such as place and circumstance, like geographical location or whether the user is on or off a company network. You can create any number of policies to cover a wide range of scenarios, specify the order in which they're executed, and create multiple rules in them.

Okta sign-on policies can specify actions to take for allowing access, such as prompting for a challenge and setting the time before prompting for another challenge.

Okta provides one default policy for each policy type, named Default. It's a required policy that applies to new applications by default or any users for whom other policies in the Okta org don't apply. This ensures that there's always a policy to apply to a user in all situations.

  • A default policy is required and can't be deleted.

  • New applications (other than Office365, Radius, and MFA) are assigned to the default policy.

  • The default policy is always the last policy in the priority order. Any added policies of this type have higher priority than the default policy.

  • The default policy always has one default rule that can't be deleted. It's always the last rule in the priority order. If you add rules to the default policy, they have a higher priority than the default rule.

In addition to the default policy, there's another policy, named Legacy, that's present only if you've 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.

Configuring sign-on policies for RADIUS applications: If you create an Okta sign-on policy from the Admin Console in SecurityAuthenticationSign On, it doesn't 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. When a policy needs to be retrieved for a particular user, for example when the user attempts to sign in to Okta, or when the user initiates a self-service operation, then a policy evaluation takes place. During policy evaluation, each policy of the appropriate type is considered in turn, in the order indicated by the policy priority. Each of the conditions associated with the policy is evaluated. If one or more of the conditions can't be met, then the next policy in the list is considered. If the conditions can be met, then each of the rules associated with the policy is considered in turn, in the order specified by the rule priority. Each of the conditions associated with a given rule is evaluated. If all of the conditions associated with a rule are met, then the settings contained in the rule, and in the associated policy, are applied to the user. If none of the policy rules have conditions that can be met, then the next policy in the list is considered.

For example, if you create a policy that 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. A rule that you might apply to the policy might be one that allows for a self-service unlock only under certain conditions. Another example of a condition might be whether a particular admin is signing in from inside or outside of your company network.

Tips:

  • A policy that contains no rules can't be successfully applied; a warning indicates that no rules exist for this policy.
  • Ensure that any restrictive rules are placed at the top of the Priority list.
  • If “Everyone” is on top, special conditions don't apply and a policy evaluation isn't unnecessary. If multiple rules are present and the conditions of the first rule aren't satisfied, Okta skips this rule and evaluates the following one.
  • For high-risk events and behaviors, be sure to set the Prompt for Factor requirement to Every time.
  • The Per device and Per session options reduce MFA for a group of users. Because they allow users to bypass MFA, they're only appropriate for low-risk, low-assurance use cases.

MFA factors and sign-on policies

The Prompt for Factor checkbox isn't active unless at least one factor has been chosen from the Multifactor page.

To access the page and choose one or more factors, go to SecurityMultifactor.

If a specific factor is specified in a policy, that factor can't be removed until it's removed from all the policies that require it. If MFA is enabled for your org, you're required to specify at least one factor. If a factor isn't specified, an error message appears on the Multifactor page.

Related topics

Configure an Okta sign-on policy

MFA enrollment policies

Password policies

App sign-on policies

Configure an MFA enrollment policy

Configure an app sign-on policy

Configure a password policy