Okta Admin Management API

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 OKTA_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
App sign-in policies: ACCESS_POLICY
Client update policies: CLIENT_UPDATE
Device signal collection policies: DEVICE_SIGNAL_COLLECTION
Entity risk policies: ENTITY_RISK
Global session policies: OKTA_SIGN_ON
IdP discovery policies: IDP_DISCOVERY
Identity claims sourcing policy: IDENTITY_CLAIM_SOURCING
Password policies: PASSWORD
Session violation enforcement policy: POST_AUTH_SESSION
Session violation detection policy: SESSION_VIOLATION_DETECTION
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 property usePersistentCookie of the default global session policy's default rule, which is read-only.
The default identity provider routing rule and the default rule of the default authenticator enrollment policy, 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.

The app sign-in policy has the following limitations:

You can have a maximum of 5000 app sign-in policies in an org. There is a max limit of 100 rules allowed per policy. When you create an app sign-in policy, you automatically also create a default policy rule with the lowest priority of 99. The highest priority that you can set an app sign-in policy rule to is 0.
When you merge duplicate app sign-in 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.

Languages

Servers

https://{yourOktaDomain}