One of the biggest differences administrators will notice when moving from Classic to Identity Engine is the different terminology as well as slightly different behavior of the main policies. When being migrated by Okta the policies will be converted, but it makes sense to have a proper look at them and make some adjustments to achieve the best results both for users and security.
Okta has established itself as the independent cloud platform for Identity and Access Management. Regularly on top of the Gartner Magic Quadrant for IAM and constantly improving the product. Like all software products, though, there are sometimes structural changes required that cannot be just removed or modified without turning the bigger wheel. This is what the Identity Engine is about. It's not a new product or a different kind of use case, it’s the known Okta platform reengineered.
→ Read an introduction to the Okta Identity Engine
New customers since November 2021 are automatically on Identity Engine. Existing customers will be migrated during 2022.
Terminology and administration
Even though they are a bit different in their capabilities and functionality, the main policies are still in Okta Identity Engine, although with new names.
Terminology and administration
“(Multi-)Factors” are now “Authenticators” in Okta Identity Engine. Okta has adjusted the terminology slightly, to align better with industry standards. A “factor” now describes a type of authenticator. For example, the authenticator “Password” is of the factor type “Knowledge”, while the authenticator “Okta Verify” is of the factor type “Possession” (+ Knowledge or Biometric, depending on the setup).
If you are using Factor Sequencing in your Classic Engine, as of now you will not be migrated to Identity Engine. Factor Sequencing for Identity Engine is still in development and will come later this year.
While other changes are mostly just renamed or moved, the biggest differences between Classic and Identity Engine are in the Authentication Policies. Previously they were called “App Sign On Policies” and configurable for every application.
Now they got a more prominent spot in the Admin Console as well as in the authentication structure. While they previously could almost be ignored if no changes had been made although they were always applied, they are now an integral part of the authentication design.
The “Global Session Policy” sets the context of the login attempt and defines a basic rule set for the session that is initiated.
Global Session Policy example
After the "Global Session Policy", before the user gets allowed access, the “Authentication Policy” and their rules define the conditions and factors which are required for allowing the user to pass to each application. *
Typical Authentication Policy example
In this example, members of the group "Contractors" are allowed to pass to these applications with a password and one additional factor (Okta Verify or phone). Other users are using the “Catch-all rule.”
*It is good to think of both the “Okta Dashboard” and “Okta Admin Console” each as an application in this context. They too have “app-level” policies, which apply to them.
Application policy rules in detail
Authentication polices allow a complex ruleset to adjust the authentication experience for the users. Each policy allows multiple rules, which are ordered by priority (first hit applies).
The rule can contain the following:
This section defines WHEN a rule is applied.
This section defines what the rule enforces.
3. Re-authentication frequency
In the last section of the rule, you can define how often users need to reenter their password or re-authenticate with all factors.
Example of re-authentication frequency
Apply authentication policies to apps
Authentication policies can be assigned to multiple applications, making it easier for administrator to separate different security requirements to different applications. Note that some apps require separate policies, like Okta Admin Console or Office 365.
Authentication policies applied to multiple applications
Application policies allow Okta administrators to more fine grain their authentication and security policies that what was previously possible with Classic Engine. App-level policies also allow to make use of further enhancements in Identity Engine, like Okta FastPass.