An authentication policy scenario for Okta FastPass
When you configure rules in an authentication policy, it's important to consider how those rules will affect device access to applications.
Example 1: device access is denied
In this policy, a device that is part of user group B is denied access if one of these conditions is true:
-
Silent device probing is not successful (this can occur when the Okta Verify service is not running in the background, trying to sign in to a Windows universal app like the native mail app, or when using an unmanaged iOS device)
-
Okta Verify is not installed (the device is not registered)
Access is denied because only rule 4 is true.
| Rule | User group | IF | THEN |
|---|---|---|---|
| 1 | A | Require registered device, managed device | Allow with 1FA |
| 2 | A | Any device state | Allow with 2FA |
| 3 | B | Require registered device | Allow with 1FA |
| 4 | Catch all | Any | Deny |
In this situation, the device is allowed access if one of the following conditions is true:
-
An administrator adds a new rule to the policy that allows User group B, with IF condition "Any device state", and THEN condition "Allow with 2FA".
-
The Okta Verify Sign in with Okta Verify button is used to sign in, instead of entering their username.
Example 2: device access is allowed
In this policy, example 1 is modified. An additional rule was added for user group B that allows a device with any device state to obtain access. Rule 4 is true for this device, so it is allowed access.
| Rule | User group | IF | THEN |
|---|---|---|---|
| 1 | A | Require registered device, managed device | Allow with 1FA |
| 2 | A | Any device state | Allow with 2FA |
| 3 | B | Require registered device | Allow with 1FA |
| 4 | B | Any device state | Allow with 2FA |
| 5 | Catch all | Any | Deny |