Add a Global Session Policy rule

Rules describe the conditions of policy behavior, like requests from a geographical location or whether the user is on or off a trusted network. There isn’t a limit to the number of rules that a Global Session Policy can have, but it must have at least one rule before it can be applied.

If you're adding rules to a new policy, start this task at step 4.

  1. In the Admin Console, go to Security > Global Session Policy.
  2. Select the policy that you want to add rules to.
  3. Click Add rule.
  4. In the Rule name field, add a descriptive name for the rule you want to create.
  5. Optional. In the Exclude users field, indicate which individual users of a group you want to exclude from the rule.
  6. Indicate your conditions.
    IF User’s IP is

    Use the drop-down menu to assign location parameters.

    • You can specify whether Anywhere, In zone, or Not in zone will prompt authentication.
    • Click Manage Configurations for Network to access your gateway settings that enable your choice of access. See Network zones.
    AND Identity provider is

    Use this drop-down menu to specify which identity provider you want to use:

    • Any: Select this option to use either Okta or Specific IdP as the identity provider.
    • Okta: Select this option to use only Okta as the identity provider.
    • Specific IdP: Select this option to use an identity provider that you specify.
      When you select this option, a field appears below this drop-down list; select the identity provider you want to use. See Add a social login (IdP) to add identity providers to this list.

    Note: This is an Early Access feature. To enable it, contact Okta Support.

    AND Authenticates viaUse this drop-down menu to specify the required means of authentication.
    AND Behavior is

    Enter a behavior type or a named behavior. For high-risk behaviors, be sure to set your secondary factor requirement to Every time. Don't combine a behavior condition with a per device or per session secondary factor requirement.

    See Security Behavior Detection types.

    AND Risk is

    Select a risk level of Low, Medium, or High. If you select High, be sure to set your secondary factor requirement to Every time. Don't combine a high-risk level with a per device or per session secondary factor requirement.

    See Risk scoring.

    THEN Access isBased on the authentication form of the previous drop-down menu, use this one to establish whether the condition allows or denies access.
    AND Primary factor is

    Select Password / IDP or Password / IDP / any factor allowed by app sign on rules.

    See Set up passwordless sign-in experience.

    AND Secondary factor

    Indicate whether a secondary factor is required. If it's required, specify how frequently users are prompted to re-authenticate:

    • Per device: This option reduces MFA for a group of users. Because it allows users to bypass MFA if they appear to be signing in from the same device (based on a browser cookie), it's only appropriate for low-risk, low-assurance use cases. It shouldn't be used with behavior conditions.

    • Every time: This option prevents users from controlling their own MFA prompts. This option is suitable for use with behavior conditions, which detect high-risk sign-in events. See End User Control of MFA Prompts.

    • Per session: This option means that users aren’t challenged again for MFA for the duration of their session unless an app's authentication policy requires it. You can set both a factor lifetime and a session expiration, but be aware that Factor lifetime is only enforced when a new session is created or if the user changes devices. Per session is only appropriate for low-risk, low-assurance use cases and shouldn't be used with behavior conditions or risk conditions.

    If a secondary factor isn't required, refer to Set up passwordless sign-in experience.

    Factor Lifetime

    If you require a secondary factor, specify how much time must elapse before the user is challenged for it. The maximum lifetime is six months.

    Session Expires After

    Specify the maximum idle time before an authentication prompt is triggered. If you require MFA frequently across all apps, create a shorter session expiration and set your secondary factor requirement to Every time.

    Five minutes before their session expires, users see a countdown timer and an option to extend their session. The maximum allowed time is 90 days.

  7. Click Create Rule.

Keep me signed in

Okta allows admins to create Global Session Policies that can minimize login friction for the user.

Admins can allow the use of Persistent Cookies, which maintains the user's Okta session cookie on the device even after the browser session is quit. Admins can also specify how often a user is prompted for a second factor when signing in to Okta. End users can opt in to this functionality by selecting Keep me signed in on the sign-in widget; this check box retains the end user’s identifier and authenticator verification information on their device for the amount of time designated by the Global Session Policy.

Authenticator verifications are cleared for end users when they sign out or when their session expires. Users who select the Keep me signed in check box are still required to pass MFA at least once on their current device.

Required secondary factor

When the Global Session Policy rule is set to Require secondary factor, once Per Device:

If users select Keep me signed in, they aren’t prompted for a second authenticator if their session expires or if they sign out, and if they haven’t cleared the device cookies and the device token is still valid.

When the Global Session Policy is set to Require secondary factor once Per Session and the Factor Lifetime is set:

Users won’t be prompted to verify additional authenticators based on the Factor Lifetime that is set in the Global Session Policy.

For example, if the Factor Lifetime is set to 10 days, after 10 days the user is prompted for secondary authenticators. When the user’s session expires, or after they sign out of the session, they’re prompted for a primary authenticator.

When the Global Session Policy is set to Password / IDP / any factor allowed by authentication policy rules:

Password can’t be used a secondary authenticator, and passwordless authentication is not available.

When the Global Session Policy is set to Password / IDP:

Security Question can be used as a secondary authenticator only for MFA/SSO. Okta recommends against using security questions in any authentication flow.

About persistent cookies

When a persistent cookie is set for a Global Session Policy rule, the Keep me signed in functionality persists the session cookie in the browser so the user stays signed in after the browser closes.

Note

Global Session Policy persistent cookies can only be configured by setting the usePersistentCookie option in the Okta API. See Session and persistent Single Sign-On.

When the usePersistentCookie is configured:

  • The API sets a cookie that lasts across browser sessions. If a user quits their browser and reopens the browser, the browser session is persisted unless the user has signed out.
  • The persistent cookie is valid until the session expires according to settings in the Global Session Policy.
  • Persistent cookies are never set for Okta admins.

Notes about Global Session Policy rules

  • Ensure that any restrictive rules are placed at the top of the Priority list.
  • If the Everyone rule is at the top of the Priority list, special conditions do not apply and a policy evaluation is unnecessary. If multiple rules are present and the conditions of the first rule are not satisfied, Okta skips this rule and evaluates the next one.
  • The Global Session Policy controls how long an overall session is valid, but re-authentication frequency is controlled by authentication policy rules.
  • An end user’s session expires according to the Session expires after setting in the Global Session Policy. At this point, end users must re-authenticate according to the Global Session Policy rules, regardless of whether they selected the Keep me signed in option when signing in.
  • When the AND Authenticates via condition is set to LDAP, the AND Primary Factor is selection has no effect. LDAP interface bind requests may still require a username and password with MFA information. See Use multifactor authentication with the LDAP Interface.

Related topics

Global Session Policies

Authentication policies

Registration of end users