Policies

The Okta Policy API enables an administrator to perform policy and policy rule operations. The policy framework is used by Okta to control rules and settings that govern many things:

• user session lifetime
• whether multi-factor authentication is required when signing in
• what MFA factors may be employed
• password complexity requirements
• what types of self-service operations are permitted under various circumstances
• which identity provider to route users to

Policy settings for a particular policy type, such as SIGN_ON policy, consist of one or more policy objects, each of which contains one or more policy rules. Policies and rules contain conditions that determine whether they are applicable to a particular user at a particular time.

See:

• Authenticator enrollment policies: MFA_ENROLL
• Authentication policies: ACCESS_POLICY
• Entity risk policies: ENTITY_RISK
• Global session policies: SIGN_ON
• IdP discovery policies: IDP_DISCOVERY
• Password policies: PASSWORD
• Post auth session policies: POST_AUTH_SESSION
• User profile policies: PROFILE_ENROLLMENT

Policy evaluation

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.

Rule priority

Rules have a priority that govern the order that they are considered during evaluation. The highest priority rule has a priority of 1. For example, if a particular policy had two rules:

• Rule A has priority 1 and applies to LDAP API scenarios.
• Rule B has priority 2 and applies to ANYWHERE (network connection) scenarios.

If a request came in from the LDAP endpoint, the action in rule A is taken, and rule B isn't evaluated. This occurs because even though requests coming from anywhere match the ANYWHERE location condition of rule B, rule A has higher priority and is evaluated first.

Default rules

Only the default policy contains a default rule. In Identity Engine, you can't delete default rules, but can edit them, except for:

• The properties maxSessionLifetimeMinutes and usePersistentCookie of the default global session policy's default rule, which are read-only.
• The default rules on the authenticator enrollment policy and the identity provider routing, which are also read-only.

Policy limitations

Different policy types control settings for different operations. All policy types share a common framework, message structure, and API, but have different policy settings and rule data. Keep in mind the following policy-specific limitations.

Authentication policy

The authentication policy has the following limitations:

• You can have a maximum of 5000 authentication policies in an org. There is a max limit of 100 rules allowed per policy. When you create an authentication policy, you automatically also create a default policy rule with the lowest priority of 99. The highest priority that you can set an authentication policy rule to is 0.
• When you merge duplicate authentication policies, policy and mapping CRUD operations may be unavailable during the consolidation. When the consolidation is complete, you receive an email.

IdP discovery policy

The IdP discovery policy has the following limitations:

• You can add up to 10 providers to a single idp policy action.
• You can define only one provider for the following IdP types: AgentlessDSSO, IWA, X509.
• You can't define a provider if idpSelectionType is DYNAMIC.
• You can't define a providerExpression if idpSelectionType is SPECIFIC.
• If a user identifier condition is defined together with an OKTA provider, sign-in requests are handled by Okta exclusively.

Password policy

The password policy is enforced only for Okta and AD-sourced users. For AD-sourced users, ensure that your Active Directory policies don't conflict with the Okta policies.

User profile policy

The user profile policy has the following limitations:

• You can't update or delete the required base attributes in the default user profile: email, firstName, or lastName.
• You can have a maximum of 500 user profile policies in an org. A user profile policy can only have one rule associated with it. Adding more rules isn't allowed.

The default rule is required and is 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. The system object determines whether a rule is created by a system or by a user. The default rule is the only rule that has this attribute. See Configure multiple identifiers.