On this page

    Configure a global session policy and authentication policies

    Identity Engine

    Note: In Classic Engine, the global session policy is called the Okta sign-on policy and an authentication policy is called an app sign-on policy.

    Note: This document is only for Identity Engine. If you’re using Classic Engine, see Configure Okta sign-on and app sign-on policies. See Identify your Okta solution (opens new window) to determine your Okta version.

    This guide explains what global session policies and authentication policies are used for and how to add and configure them in your Okta org.

    Learning outcome

    Know the purpose of a global session policy and authentication policies and be able to configure them.

    What you need

    Overview

    Policies help you manage access to your applications and APIs. You can restrict access based on several conditions such as user and group membership, device, location, or time. You can also require more authentication steps for access to sensitive applications. More authentication steps might include confirmation of a push notification to a mobile device or re-authentication through an SMS one-time passcode.

    Note: See the Policies concept for more information on all available policies and how to use them.

    Global session policies

    Global session policies help control who can have access and how a user gains access to Okta. This includes whether they're challenged for more factors and how long they're allowed to remain signed in before reauthenticating. A global session policy supplies the context necessary for the user to advance to the next authentication step after Okta identifies them.

    Multiple options

    You can configure a global session policy to require any of the factors that you set up (opens new window). Then use the primary and secondary factor conditions in a rule to define which factors are evaluated. For example, add a rule that prompts for more factors when you want only users who are inside your corporate network (opens new window) to have access.

    Note: If you select Any factor used to meet the Authentication Policy requirements, you remove the global password requirement from the global session policy. This transfers responsibility for defining and enforcing authentication to each of your authentication policies instead. See Configure passwordless authentication (opens new window).

    You can specify any number of global session policies and the order in which they’re executed. If a policy in the list doesn't apply to the user trying to sign in, the system moves to the next policy. There’s one required organization-wide policy named default. By definition, the default policy applies to all users.

    Note: You can't change the Maximum Okta global session lifetime setting of the default global session policy rule.

    Authentication policies

    In addition to the global session policy, you can configure authentication policies for each app for extra levels of authentication. You can also share authentication policies across multiple apps (opens new window).

    When you add an app, it's automatically assigned the shared default policy. This policy has a single catch-all rule that allows a user access with only one factor. You can add as many rules to the default policy as you need. However, remember that the changes are applied to both new and existing apps that are assigned the shared default policy.

    You don’t have to use the default authentication policy. You can create a policy specifically for an app, or you can add an app to another existing shared policy (opens new window). If you change an app’s sign-on requirements, you can modify its policy or switch to a different shared policy using the Authentication Policies page (opens new window).

    Note: There can be only one authentication policy per app.

    Configure sign-on policies for common scenarios

    This guide provides step-by-step instructions to configure a global session policy and an authentication policy for three common scenarios:

    Prompt for an additional factor for a group

    Configure a global session policy to prompt a user for a factor authenticator (opens new window) when the user is a member of a certain group.

    Create the policy container

    1. In the Admin Console, go to Security > Global Session Policy.

    2. Click Add New Global Session Policy. The Add Policy window appears.

    3. Enter a Policy Name, such as Require MFA for Contractors, and then enter a Policy Description.

    4. Enter the group name that you want to apply the policy to in the Assign to Groups box. In this example, specify the Contractor group in the org. You must create groups before assigning them to a policy.

    5. Click Create Policy and Add Rule.

    Create the rule

    1. In the Add Rule window, add a descriptive name for the rule in the Rule name box. For example, name it Require contractors to use MFA once per session.

    2. If there are any users in the Contractor group that you want to exclude from the rule, enter them in the Exclude Users box.

    3. Configure IF conditions, which define the authentication context for the rule. For this use case example, leave the defaults. For other use cases where you want to assign location parameters, specify location prompts in the IF User’s IP is dropdown box. For example, you can prompt a user for a factor when they aren't on the corporate network.

    4. Configure THEN conditions, which define the authentication experience for the rule. For this use case example, select that the session is established with the user entering A password. Also, ensure that Multifactor authentication (MFA) is Required so that users of the Contractor group are prompted for a secondary factor before they’re granted access.

      Note: Click the authenticators link for quick access to the Authenticators (opens new window) page to configure the authenticators that you want to use.

    5. Select how users are prompted for a secondary factor in a given session. In this example, leave the default of At every sign in selected. Users are challenged for MFA every time they sign in.

    6. Configure the time settings for the rule. Use these fields to specify the maximum idle time before an authentication prompt is triggered. The maximum allowed time for this option is 90 days. This isn't the total connection time. This is idle time before users see a countdown timer at the 5-minute mark of remaining session time.

    7. Click Set time limit and leave the default time settings.

      Note: You can also set the maximum session lifetime value (opens new window) using the Okta APIs. If you previously set this value using the API, you can't exceed that maximum in the Admin Console. Setting a value over the API maximum results in an error.

    8. Click Create Rule.

    Note: After you create a policy, you must close all active sessions for the new policy to take effect.

    Prompt for an additional factor when a user is outside the US

    You may want a rule that requires all default Okta users to provide a password. But you also want all Okta users outside of the United States to provide both a password and another factor to access your app. You can use the default authentication policy’s catch-all rule that challenges all users to provide a password. Then, create another rule that challenges all users not in the United States to provide both a password and another factor each time that they sign in.

    Configure another rule for the default authentication policy to prompt a user for an additional factor when the user is outside of the United States.

    Note: You can add as many rules to the default authentication policy as you want. But remember that changes to the default authentication policy are applied to all new apps because it's a shared app policy.

    Select the default policy and add a rule

    This example assumes that you've already set up a Dynamic Zone (opens new window). In this example, use a dynamic zone defined for IP addresses within the United States.

    1. In the Admin Console, select Security > Global Session Policy.

    2. Select Default Policy and then click Add rule. The Add Rule dialog appears.

    3. Enter a Rule name such as Prompt for an MFA factor when a user is outside the US.

    4. Configure IF conditions to define the authentication context for the rule. Select Not in zone from the AND User’s IP is dropdown list.

      Note: You can click the Go to Network Zones link to access the gateway settings that enable your choice of access. A network zone (opens new window) is a security perimeter used to limit or restrict access to a network. It can restrict access based on a single IP address, one or more IP address ranges, or a list of geolocations. You can also create network zones using the Zones API (opens new window).

    5. In the text box, enter the dynamic zone name and then select it when it appears in the list.

    6. Configure THEN conditions to define the authentication experience. For this use case, leave the default of Allowed for THEN Access is.

    7. For Establish the user session with, select Any factor used to meet the Authentication Policy requirements.

    8. Ensure that MFA is Required. Users who sign in to your app from a non-US IP address are prompted for an additional factor.

    9. Select how users are prompted for a secondary factor in a given session. For example, select At every sign in so that users are prompted at every time they sign in.

    10. Configure the time settings for the rule.

    11. Click Create rule.

    Note: You can use the Applications (opens new window) and Policies (opens new window) APIs to assign an app to an authentication policy. You need the application ID and the policy ID for this API request. Make a PUT /api/v1/apps/{appId}/policies/{policyId} request. No HTTP body is necessary for the PUT request. Then, to check that the assignment was successful, make a GET /api/v1/apps/{appId} request. The successful response contains information on the policy associated with the app.

    Prompt for a passwordless sign-in flow

    In this example, create a policy that allows a specific group, Full time employees, for example, to sign in without using a password. This policy applies to users in that group only when they're connected to a corporate network. Before you create this global session policy, complete these steps:

    Create a passwordless policy

    1. In the Admin Console, select Security > Global Session Policy.

    2. Create a policy container and assign it to the Full time employees group.

    3. Click Create policy and add rule. The Add Rule dialog appears.

    4. Enter a Rule name.

    5. Configure IF conditions, which define the authentication context for the rule. For IF User's IP is, select In zone.

    6. Select the Corporate Network zone.

    7. Leave the default AND conditions.

    8. Configure THEN conditions, which define the authentication experience for the rule. For this use case, leave the default of Allowed for THEN Access is.

    9. For Establish the user session with, select Any factor used to meet the Authentication Policy requirements.

    10. For Multifactor authentication (MFA) is, select Required so that users in the Full time employees group are prompted for a secondary factor before they’re granted access.

    11. For Users will be prompted for MFA, select how users are prompted for a secondary factor in a given session. For this example, select At every sign in.

    12. Configure the time settings for the rule.

    13. Click Create rule.

    See also

    Edit This Page On GitHub