If you use 1Password Device Trust Connect to integrate with Okta, Kolide determines what the status of a device needs to be in order to authenticate, while Okta determines when Device Trust is required. These two pieces work together to dictate whether a device and a user can sign in.

Because Okta is where you define what’s required for a user to access your protected applications, a SAML authentication outage results in a full outage in which no authentication requests through 1Password Device Trust succeed.

The best way to prepare for this possibility is to create backup rules in your environment that you can quickly activate in case of an outage.

Step 1: Make Sure Admins Can Access Okta Administrative Console

If you experience a SAML authentication outage with Okta, the fastest workaround is for one or more Okta super administrators to sign in to the Okta Administrative Console and turn on your “break-glass” rules, so that users won’t need 1Password Device Trust to sign in.

First, consider your administrators and what authenticator requirements they need to access the Okta Administrative Console. The baseline recommendation is to allow your admins access to multiple, redundant authenticators when accessing the portal. You can also build in additional complexity based on the needs of your organization.

Some options for additional complexity include:

1. (Recommended) Shared Super Admin Credentials: A shared super admin account whose credentials are stored in 1Password in a shared vault. You can add a specialized rule to the authentication policy governing the admin console, prioritized to the top of the rule stack and scoped only to this account, allowing the user to authenticate successfully with only a username and password. You can also leverage 1Password’s one-time password capabilities for multi-factor authentication in this flow. Your organization’s internal governance policies will determine how you must account for the use of this shared credential.
2. Okta Workflow Group Membership: An Okta Workflow set up to add administrators to a “break-glass” group. This workflow must have an external stimulus that will programmatically initiate the addition of admins to the group when necessary. You can add a specialized rule to the authentication policy governing the admin console, prioritized to the top of the rule stack and scoped only to this group, allowing members of the group to successfully authenticate with only a username and password or with a secondary authenticator that is not 1Password Device Trust. We recommend that you also build the workflow to transition admins out of the break-glass group, falling back to their original requirements after a designated period of time such as two hours.

Step 2: Create “Break-Glass” Rules

In your Okta Administrative Console, create “break-glass” rules set with the highest priority for each authentication policy where 1Password Device Trust is required. Configure these rules to use as many authenticator options other than 1Password Device Trust as your organization supports.

Scope your “break-glass” rules to include either all users in all cases, or to reflect the scoping requirements of the rule enforcing 1Password Device Trust. You can also include any type of group, user, or platform scoping that you need.

A break-glass rule may look like:

After you create and prioritize a rule, set it to deactivated. Repeat for any other authentication policies where you are enforcing the use of 1Password Device Trust.

If an Outage Occurs

If a SAML authentication outage occurs, have your administrators:

1. Sign in to the Okta Administrative Console.
2. Enable the “break-glass” rules for each authentication policy that uses 1Password Device Trust.
3. After service has returned, deactivate the “break-glass” rules and return to normal usage.