Context re-evaluation with FastPass

Cyber attackers are constantly evolving and developing more sophisticated methods. Phishing and social engineering attacks are increasing, and as quickly as organizations implement more advanced authenticators, attackers adapt to them. One emerging strategy involves stealing session tokens directly from users' web browsers, presenting a fresh challenge in the ongoing battle for digital security.

At Okta, preventing attackers from accessing sensitive information on our users’ devices is a top priority. Okta FastPass helps thwart these kinds of attacks using context re-evaluation.

What is context re-evaluation, and what are its benefits?

FastPass silently performs security checks every time you access a new app and prevents further access if Okta determines the device identity or posture has changed materially, which may indicate a compromised session. This capability to handle device and user risk changes offers a massive benefit by preventing stolen sessions from accessing downstream applications.
 

V0 6xsyUOy P3JGr2Tiw ggFcBO7UmINv93MBjVonOey21ny4BqZKuqeZGr0SZh8 7tYBEtH3nAdOIxF50mozB1uHJXxbAWgk6zW9zF3pZNZzFKv5trODPyW4GeGWjbsRcsEfPtZtbCShOldAJgyS10

 

How do you configure Okta FastPass with context re-evaluation?

Step 1: Add Okta Verify as an authenticator.

Step 2: Create an authenticator enrollment policy. In the “Eligible authenticators” section, ensure Okta Verify is set to “Required.”

Step 3: Create an authentication policy and assign application(s).

  1. Add an authentication policy rule with the following settings.
    1. Device state” is set to “Registered.”
    2. “The User must authenticate with” is set to “Possession.”
    3. The “Phishing Resistant” checkbox is checked.
    4. The “Hardware Protected” checkbox is checked (recommended).
    5. You may also set the “User's group membership includes” to a specific group for testing purposes.
    6. In the “Re-authenticate frequency” section, set “Re-authenticate after” to two hours. This value can be modified based on business needs.
  2. Edit the default Catch-all Rule and set “Access” to “Denied.”

Please follow the steps listed in Step 4 to ensure your users don’t get locked out. 

  1. Add downstream application(s) to the policy.
    1. Select the “Applications” tab and then click “Add app.”
    2. Click “Add” for each app you want to add to this policy.
    3. Click “Close.”

Step 4: Verify using the Access Testing Tool (recommended)

The Access Testing Tool enables you to run simulations of real-world user requests to access an application. The result shows whether the user would be allowed access to the app and which rules and settings of your configuration were matched to create the authentication and enrollment requirements.

  1. In the Admin Console, go to “Reports > Access Testing Tool.”
  2. Application: Select the application used in Step 3.
  3. Username: Enter the username of a user whose access you want to test. Select it from the list when it appears.
  4. Set the Device State to “Registered.”
  5. Modify other options as needed
  6. Click “Run Test.”
     

Review the results in the “Results” section of the page. In the Matching Policies section, all policies that matched the criteria appear if the test was successful. In the “Sign-in journey” option, select the “Authenticate” tile. This option shows which policies contained the authenticators and authentication requirements that matched the criteria you configured in the simulator. Here, you should see the authentication policy created in Step 3.

Step 5. Add additional downstream applications to the authentication policy (optional).

Step 6: Add a device assurance policy (recommended).

Device assurance checks include sets of security-related device attributes. By adding device assurance checks to authentication policy rules, you can establish minimum requirements for devices with access to systems and applications in your organization.

  Step 6.1: Add a device assurance policy.

   Step 6.2: Add device assurance to an authentication policy.

Now, let’s see context re-evaluation in action.

 

 

What’s next?

Okta is committed to continuously improving how FastPass can deliver even greater security to organizations. We’re currently working with browser vendors on a standard solution to prevent session cookies from being stolen and used on any device other than the original device to which they were granted.

Have a question about FastPass or Device Security? Join the Okta Devices and Mobility community board and start a conversation.

Have questions about this blog post? Reach out to us at [email protected].

Explore more insightful Engineering Blogs from Okta to expand your knowledge.

Ready to join our passionate team of exceptional engineers? Visit our career page.

Unlock the potential of modern and sophisticated identity management for your organization.

Contact Sales for more information.