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.
Authentication process
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:
1. IF
This section defines WHEN a rule is applied.
2. THEN
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
