A study of Okta authentication - Policies

Welcome to the second article in the Okta authentication series. Although this article will not cover authentication flows per se, we will survey the different types of policies Okta provides and their purpose. As an Okta admin, you need to be aware of the entire policy ecosystem to effectively leverage them when conceptualizing, configuring, and rolling out an authentication strategy for your company.

What are Policies?

Policies enable you to enforce a layer of governance over your authentication and authorization flows in Okta. Policies are used to control the rules and settings that govern user sessions, your tenant password complexity requirements, what factors are required or optional when you log in, and other aspects such as what self-service operations are permitted under which conditions. Policies work hand-in-hand with rules. Per Okta, to determine if a policy is applied to a user attempting to sign in, the platform evaluates the conditions of the policy and its rules:

• Policies contain groups of resources that require similar treatment, such as apps with the same security characteristics or user groups with the same account setup requirements.
• Rules describe the conditions of policy behavior, such as requests from a geographical location or whether the user is on or off a trusted network. Every policy must have at least one rule before it's applied.

Keep in mind that for each type of policy, Okta provides a default policy that applies to all users in the organization’s tenant, unless a more granular policy of the same type is configured with a higher priority. This policy is referred to as a Default Policy and cannot be deleted. Simply put, if nothing else has been defined and all you have is this default policy, the Default Policy will be the policy that gets triggered and determines what factors are presented to fully authenticate a user and what applications that user has access to. For example, a user in your tenant who has successfully authenticated but has not been assigned access to any of your company’s applications will have a pretty bare Okta Dashboard.

Now that we have defined these core concepts and introduced what a default policy is, we will proceed to review the types of policies you have available. We will start by reviewing Global session policies and authentication policies. 

Global Session and Authentication Policies

At a high level, Global session policies and authentication policies are used to enforce a level of confidence that the user signing in to an application is also the person who owns the account. This level is measured via the various Okta factors available and which we studied in the first article of this Authentication series: Maximize security with various Okta authentication methods (salto.io). As we studied there, a user who authenticates with both a knowledge factor and a possession factor has a much higher assurance level than a user who authenticates with only one factor. In that first article, our hobbit friends Merry and Pippin were required to present a password and verify a second factor via the Okta Verify authenticator app.

Global session policies supply the sign-in context necessary for the user to advance to the next authentication step after they have been identified by Okta. They also specify actions to take, such as allowing access, prompting for a challenge, and setting the time before prompting for another challenge. (Sign-on policies and rules | Okta)

For our hobbits from the Shire, this meant establishing the user session with a password and requiring MFA in the first iteration of our newly deployed authentication flow. Global policies also allow you to define an MFA lifetime, a Maximum Okta global session, and a session lifetime, which we defined as follows for our hobbit friends -

• Session Lifetime = 12 hours
• Maximum Okta global session lifetime = 5 days
• MFA lifetime = 7 days

Please keep in mind that MFA will be remembered for the device cookie, therefore as long as the configured MFA lifetime for the device cookie is valid, users will not be prompted for MFA when signing in. You always want to make sure to keep the level of friction low whenever possible, namely when your users are not going through a super sensitive flow.

Now, if you remember, before we created our custom Sandbox-2Factor-Policy policy and rule, we already had a policy/rule in our Okta tenant. This is an example of a Default Policy specifically in the context of our Global session Default policy:

If we had not defined a new Sandbox-2Factor-Policy Global Session, our hobbits would be asked to authenticate with a Password, no MFA, and be able to maintain a 2 hour Maximum global session idle time.

In contrast to Global Session policies which act as a blanket to your entire tenant, you can also define what’s called Authentication policies which work alongside global session policies. Authentication policies are specific to applications. You can have an authentication policy for each of your applications, or you can create a few and assign them to a group of apps - it’s up to you. Just understand that a user will gain access to Okta through the global session policy but will not automatically have access to any apps. What a user needs to fulfill to access a specific app is controlled by the authentication policies assigned to that app in your tenant. In our case, we created a new authentication policy called 2F Password + Okta Verify with 2 rules: one designed for high-risk access which requires a password and another factor effectively every time a user attempts to sign in to the resource. Notice here we can use similar factors as our regular authentication with a custom Global session policy, however because this rule is meant for high risk access, users are required to re-authenticate every time they access the resource.

In addition, we have a Catch-all rule for this policy which enables access to the user by presenting any 2 factor types. This rule will trigger for all non-high-risk events and therefore the re-authentication frequency is set to every 12 hours instead of every single time. These 2 different rules serve as an initial attempt to provide a level of risk-based authentication (at least when accessing applications) and will serve as a baseline for the future. In the next article, we will dig deeper into risk-based authentication and how this can be leveraged across the board.

Password and MFA Enrollment Policies

Working side-by-side with your global session and authentication policies, you have two other supporting sets of policies - Password and MFA enrollment policies - that govern the requirements for your users’ passwords and how other factors are enrolled. If you as an admin configure Password as one of your tenant Authenticators, you will be provided a Default Policy similar to the default global policy this time with certain complexity requirements and a rule which defines terms for Password Change, Password reset, and whether Self-Service Account Unlock is enabled. For reference, this is what the default policy and rule looks like:

In our hobbits scenario, we created a new custom password policy to include your password requirements as defined by your company’s strategy. In our hobbit’s case, we upped the password requirements to require 10 characters instead of 8, as well as requiring a mix of lower and upper case letters, numbers and symbols. Setting password requirements is a balancing act. You want to make them not too easy but also not too complex, and what you should and should not do varies by industry - a financial institution will usually have more stringent requirements than a website to search for recipes, for example.

An Authenticator enrollment policy is evaluated alongside password policy. Authenticator enrollment policies determine when and how an end-user is prompted to enroll available authentication factors such as a password, biometrics, or an authenticator app like Okta Verify or Google Authenticator. If an end-user is signing in and has not enrolled required factors, they will be prompted to complete the enrollment. They will also be prompted to enroll any factors marked as optional, although they can choose not to proceed with enrollment for those. Similar to all others, Okta provides you with a Default enrollment policy assigned to every one of your users. You should review what this enrollment policy provides and whether it fulfills your specific requirements. As of today, this is how our Default enrollment policy looks like.

It is generally recommended to create your own custom policy to match different scenarios and how the policy should apply. To configure a new enrollment policy, go to Security -> Authenticators and locate the Enrollment tab. In line with our other definitions, we are requiring enrollment of Okta Verify plus a Password, and have Email as optional. In our case, the Email possession factor is leveraged for Password Resets flows and allows users to authenticate with a One-Time Passcode (OTP) or email magic link that is sent to their primary email address. Except for admin users, a user’s primary email address is verified during Self-Service registration.

A few final thoughts

We hope you found this article helpful in understanding the different policies Okta has available. Before you start configuring these, figure out what your strategy will be. What factors would you like to include? Will you create different policies for certain applications? Will you require an extra MFA step for more sensitive applications, can you leverage risk-based authentication? We will cover risk-based authentication in the next article of the series. Once you have a baseline, align your key stakeholders on a simple but consistent naming convention for your policies and rules that all admins should follow.

Finally, as always, devise an iterative test plan and roll out - you can release new configurations to certain network segments and/or groups. Try to get a small group onboard who is excited to test new features still not ready for prime time and who is willing to provide a loop of invaluable feedback that you can then incorporate into later iterations.

You can assign of these IP is Anywhere, Allowed if required authenticators are missing

You can define Network requirements and roll out based on a subset of your network

You can also control whether you allow your end users to enroll the factors, or if this is disallowed.