From Okta Classic to OIE:

the Fundamentals - Part 2

How will it look?

In Part 1, in the assurance section, we drafted a very simple low, medium, high assurance model. We can now craft the authentication policies that will implement that model.

In this simple model, we will have one Global Session Policy for all assurance levels (you might want to apply it to a group of users that will be under this model). This policy routes to the app-level authentication policy, like this one (in the admin console Security>Global Session Policy>[rule]):

Global Session Policy Rule

Next, we need to craft one authentication policy for each one of our ‘bucket’, and then assign the right level of assurance to each one of our Apps. Assigning policy to Apps is trivial, let’s focus on the three levels of assurance.

Low Assurance App-level Policy

To put this one in place, we will need to do the following in the admin console: create an authentication policy with a rule that requires password only, like this one:

Authentication policy, Low Assurance Rule

End user experience

The end user will be prompted by Okta to enter his username and password.

Medium Assurance App-level Policy

And for the medium one, the rule will look like this:

Authentication policy, Medium Assurance Rule

End user experience

The end user will be prompted by Okta to enter his username and password, then one additional factor, Okta Verify code in this example.

High Assurance App-level Policy

And finally for the high assurance level, craft a rule like that:

Authentication policy, High Assurance Rule

This is a very simple model, and we focused on the basics with very simple policies and omitted network, location, device and all other context, but we wanted to show you the key concepts and ideas so that you can start projecting how it would work in your specific environment. 

End user experience

The end user will be prompted by Okta to enter his username and in this case can use Okta Verify with biometrics (assuming Okta Verify has been installed and biometrics have been enrolled).

Conclusion and what’s next

This article is focused on the minimum fundamentals that need to be understood for an administrator, and a top level comparison of how they materialize in OIE versus Classic.

There is much more into OIE than these fundamentals. For example, we have not discussed the Device Assurance Model that replaces Device Trust - this will be the object of another article.

There are much more details and capabilities for authenticators, global sign-on and authentication policies, please refer to the documentation for in-depth understanding:

• Okta Identity Engine Hub
• Authentication Policies Deployment Guide
• Passwordless Authentication Deployment Guide
• Device Context Deployment Guide

We skimmed through a few most important concepts in this article. In the following post, we will practical look at ‘before’ and ‘after’ the upgrade process, with screen capture to visualize the difference in a practical way.