To create an Okta sign-on policy, click Add New Okta Sign-on Policy. In the screen that opens, enter any desired policy name and description.
You can specify that a policy can only be applied to certain groups. To assign a policy to groups, enter the desired group names in the Assign to Groups field. The group names must already exist before assigning them to a policy. When done, click Create Policy and Add Rule.
When a policy is evaluated, the conditions in the policy are combined with the conditions in the rule. The rule is applied when all these conditions are met. A policy with no rule cannot be applied.
In addition, the order in which you add policies is also important. The first policy that matches the rule is applied; no other policies will be applied once the conditions have been met.
- Once a new policy has been created, you must close all active sessions for the new policy to take effect.
- Sign-on policies do not affect API token validity or lifetime. See API token management
Create an Okta sign-on policy
After you create a new policy, close all active sessions to activate the new policy.
In the Admin Console, go to Security >Authentication.
Click the Sign On tab.
Click Add New Okta Sign-On Policy.
Complete these fields:
Policy Name: Enter a name for the sign on policy.
Policy Description: Optional. Enter a description for the sign-on policy.
Assign to Groups: Enter the name of a group to which the policy should be applied. The policy can be applied to multiple groups.
Click Create Policy and Add Rule.
Add an Okta sign-on policy rule
Click Add Rule to add a rule to a policy. Complete the following fields as needed.
|Rule name:||Add a descriptive name for the rule you want to create.|
|Exclude users:||If needed, you can exclude individual users of a group from the rule.|
||Use the drop-down menu to assign location parameters. You can specify what kind of location will prompt authentication.|
|Manage configuration for Network:||Click the Manage Configurations for Network link to access your gateway settings that enable your choice of access. For details on using this option, see the Public Gateway IPs section of the Using the Okta Security Page.|
||Use this drop-down menu to specify the required means of authentication.|
||Type the name of an existing behavior that was previously created. To add a behavior, start typing a behavior name; a drop-down list of all matching defined behaviors appears from which you can select the behavior. Repeat for each additional behavior you want to add. When you add multiple behaviors, they are treated as OR conditions. See Add a behavior to a sign-on policy rule.|
||Based on the authentication form of the previous drop-down menu, use this one to establish whether the condition allows or denies access.|
|Prompt for Factor:||Appears as available only when at least one factor type is enabled. Selecting this box also displays radio buttons that determine whether the prompt is triggered per a device, at every sign-on, or per a session time that you specify. Choosing Every Time does not allow end users to control MFA prompts. For details on the user experience for these options, see End User Control of MFA Prompts.|
|Remember Device By Default:||Enabling this feature will auto-select the end user option upon sign-in: Do not challenge me on this device again.|
|Manage configuration for Multifactor Authentication:||Click the Manage Configurations for Multifactor Authentication link for quick access to the Authentication page and the Multifactor tab. See Configuring Multifactor Authentication for details about each of the authentication options. Select the box to display radio buttons that determine whether the prompt is triggered per a device, at every sign-on, or per a session time that you specify. When specifying per session, note that sessions have a default lifetime as configured, but sessions always end whenever users sign out of their Okta session.|
|Factor Lifetime:||Use this drop-down menu to specify how much time must elapse before the user is challenged for MFA. The default lifetime is 15 minutes, and the maximum period is 6 months. Setting a factor lifetime is a way for end users to sign out for the amount of time noted in the Factor Lifetime and not have to authenticate again with MFA at the next sign in. End users must check a box to confirm that the setting should be applied. An example is Do not challenge me on this device for the next 15 minutes. In the case, after signing out, there is no MFA prompt if the new sign in is within 15 minutes of the last sign in with MFA. If users do not check the box, they are always prompted for MFA. The time since the last sign in is noted in the bottom of the Dashboard; however, end users must refresh the screen to see the updated value.|
||Use this drop-down menu to specify the maximum idle time before an authentication prompt is triggered. The maximum allowed time for this option is 90 days. This is not the total connect time. The default session lifetime is 2 hours. This is idle time before users see a countdown timer at the 5-minute mark of remaining session time.|
You can set the maximum session lifetime number through the Okta API. If you previously set this number with the API, you cannot exceed that maximum here in the Okta app. Setting a number over the API maximum will result in an error.
If you add multiple sign-on policies, only the first one that matches criteria you selected will be applied.
Global sign-on policy actions
- Change the order of all policies except the default policy by grabbing the dotted bar next to the policy name, as shown to the left of policy 1 below, and moving the policy to the desired position in the list.
- Change the order of rules within a policy by grabbing the bar to the left of a rule name.
- Add a new policy by selecting Add New Okta Sign-on Policy.
Individual sign-on policy actions
You can perform the following actions that affect only the policy that is selected. Click the policy name in the list to select it—the selected policy displays in blue.
- Activate or deactivate the selected policy. If you deactivate a policy, it will not be applied to any user, but you can reactivate it later.
- Click Edit to edit the policy.
- Click Delete to delete a policy. You cannot delete the default policy. A deleted policy cannot be recovered.
- Click Add Rule to add a rule to the selected policy. Within a policy, you can activate, deactivate, edit, or delete a rule.
- To view details about a rule, click the rule name under Add Rule.
If you check the Prompt for Factor checkbox, as shown below, three options appear that affect how end users are prompted for MFA in a given session.
Two of these options allow end-users to control these prompts while one disallows it.
- Per Device: provides the option Do not challenge me on this device again on the end user MFA challenge dialog box. This option allows prompts solely for new devices.
- Every Time: end users are prompted every time they sign in to Okta and cannot influence when they are prompted to provide a factor.
- Per Session: provides the option Do not challenge me on this device for the next (minutes/hours/days) on the end user MFA challenge dialog box. You specify the Factor Lifetime in the accompanying Factor Lifetime field. When specifying per session, note that sessions have a default lifetime as configured, but sessions always end whenever users sign out of their Okta session.
End users that sign in using the AuthN API will have their sign on policies evaluated first before their password or other factor is verified. This evaluation helps to reduce the number of account lockouts that occur across an org.
If the sign on policy is set to
deny, the user's sign on attempt is rejected and prompted with the following generic error:
Authentication failed. In this scenario, the counter for failed logins is not incremented but instead, an event indicating a pre-auth sign-on policy evaluation is triggered.
- There are no visible UI changes or required setup in the admin console to enable this back-end feature.
- This policy does not work on initial authentication for newly created accounts via JIT provisioning. The end user account must exist in Okta for it to be affected by this policy.
- This policy does not prevent users from resetting their credentials from a denied location.