App sign-on policy migration

Authentication policies in Identity Engine have similar parameters to the app sign-on policies in Classic Engine, though there are some important differences. This table describes the configuration tasks for authentication policy rules in Classic Engine and Identity Engine.

Task

Classic Engine

Identity Engine

Name a rule Rule name Rule name
Specify users to apply this rule to
  • All users assigned to this app (default)
  • Select groups
  • Select users
  • Exclude groups
  • Exclude users
  • Any user type assigned to this app (default)
  • Select groups
  • Select user types

Both the user selections and user/group exclusions are migrated, but they won't appear as configurable conditions in any of your newly created rules.

Specify where a user must be to access the app If the user is located:
  • Anywhere (Any IP)
  • In zone (Specific)
  • Not in zone
User's IP is:
  • Any IP
  • Any network zone defined in Okta
  • In any of the following zones (specify zones)

The Not in zone exclusion is migrated from Classic Engine, but it won't appear as a configurable condition in any of your newly created rules.

Configure client or device Apply rule to specific platforms according to your Client Access Policies (CAPs).

Apply rules to trusted and untrusted devices.

CAPs are migrated but rules for trusting and untrusting devices are not. You need to create new rules for registered and unregistered devices.
Indicate the acceptable risk score This isn't available in Classic Engine app sign-on policies. Apply the rule only to app sign-on event with a specific risk score.
Custom expressions This isn't available in Classic Engine app sign-on policies. Apply the rule only when a custom expression is true.

Access

When all of the conditions are met, access is:
  • Allowed
  • Denied
When all of the conditions are met, access is:
  • Denied
  • Allowed after successful authentication
Authentication requirements
  • Prompt for password re-authentication (duration)
  • Prompt for factor (frequency)
Apply assurance requirements to access the app. 
  • Specify when a user is prompted for re-authentication.
  • For password selection, specify durations for password re-authentication and non-password re-authentication.

The most significant addition to Identity Engine policies is the assurance requirement: users who meet all conditions of an authentication policy authenticate into the app only with the proper assurance requirements. Other Identity Engine enhancements include risk scoring and custom expressions, which ensure that users meet customized security levels before they are allowed access. And while Classic Engine admins were able to exclude users and groups in an app sign-on policy, in Identity Engine the exclusion option is not available for new rules.

Classic Engine to Identity Engine migration scenarios

When you set up an app sign-on policy in Classic Engine, all Client options are selected by default. You add rules based on who the users are, which groups they belong to, their device's client and platform, and whether they are on or off network.

When you upgrade to Identity Engine, your Classic Engine app sign-on policies migrate with a few conditions.

Policy names

In Identity Engine, migrated policies are named for their applied app (<appname> policy).

Default policies

Apps in Classic Engine that used the default app sign-on policy migrate to an Okta Identity Engine authentication policy with the default catch-all rule enabled. Apps that use only the catch-all rule allow access to any user who is assigned to the app, without additional authentication (beyond what is required in the Global Session Policy).

  • IF User's type is: Any
  • AND User's group membership is: Any
  • AND Device identity is: Any
  • AND User's IP is: Any zone
  • AND Risk: Any
  • AND The following custom expression is true: N/A
  • THEN Access is: Allowed
  • AND User must authenticate with: Any 1 factor type 
  • AND Possession factor constraints are: N/A
  • Okta Verify user interaction: Always required
  • Password re-authentication frequency is: Once per device

Every app in Okta Identity Engine has the catch-all rule in its policy. The catch-all rule can be edited, but for more customized access you can add more rules and prioritize them.

Re-authentication + factor verification

Classic Engine app sign-on policies with re-authentication and factor verification enabled migrate to an Okta Identity Engine authentication policy with password and any additional factor enabled. Re-authentication frequency is determined by the duration in the Classic Engine policy. For example, a Classic Engine policy that requires password re-authentication every two hours and a prompt for factor every time migrates to an Identity Engine policy rule of:

  • IF User's type is: Any
  • AND User's group membership is: Any
  • AND Device identity is: Any
  • AND User's IP is: Any zone
  • AND Risk: N/A
  • AND The following custom expression is true: N/A
  • THEN Access is: Allowed
  • AND User must authenticate with: Password + Another factor
  • AND Possession factor constraints are: N/A
  • Okta Verify user interaction: Always required
  • Password re-authentication frequency is: 2 hours
  • Re-authentication frequency for all other factors is: Every sign-in attempt

Multifactor with no re-authentication

Classic Engine app sign-on policies that require multifactor every time with no re-authentication migrate to an Okta Identity Engine authentication policy that requires a possession factor for authentication with a re-authentication interval equivalent to the Classic Engine settings.

  • IF User's type is: Any
  • AND User's group membership is: Any
  • AND Device identity is: Any
  • AND User's IP is: Any zone
  • AND Risk: N/A
  • AND The following custom expression is true: N/A
  • THEN Access is: Allowed
  • AND User must authenticate with: Possession factor
  • AND Possession factor constraints are: N/A
  • Okta Verify user interaction: Always required
  • Re-authentication frequency for all other factors is: Every sign-in attempt

Related topics

App sign-on policy changes