Best Practices for Configuring an Okta Global Session Policy for Network Restriction

When configuring strict requirements to limit access to specific IP networks, omitting an unconditional default rule allows evaluation to continue to the next policy if Okta does not explicitly deny the user. To restrict access based on explicit network zones appropriately, configure a dedicated policy containing two rules specifically based on the required network zones rather than omitting the default rule. Okta strongly recommends leaving default policies and rules in their original state to prevent accidental lock-outs.

• Okta Identity Engine (OIE)

• Okta Classic Engine

• Customer Identity and Access Management (CIAM)

• Global Session Policy

• Network Zones

What are the best practices for configuring a Global Session Policy for network restriction?

Okta strongly recommends leaving default policies and rules in their original state to prevent accidental lock-outs. Create new policies and rules to run tests with dedicated groups. This confirms expected functionality before applying changes to all users. To restrict access based on explicit network zones appropriately, configure a dedicated policy containing two rules specifically based on the required network zones rather than omitting the default rule.

Okta uses priority as the primary factor during policy evaluation. Okta evaluates the first policy by checking group assignments, verifying rule conditions based on priority, and moving to subsequent rules or policies if conditions do not match.

• Okta checks if the user belongs to the assigned group.

• If the user belongs to the group, Okta verifies whether the user satisfies all conditions of the highest-priority rule.

• If the conditions match, Okta allows or denies access based on the rule configuration.

• If the conditions do not match, Okta moves to the next rule.

• If no other rule exists within the policy, Okta evaluates the next policy.