Introducing Factor-Based Device Trust with VMware and Okta

In 2018, VMware and Okta jointly released the ability to share device trust signals between Workspace ONE Access (formally known as VMware Identity Manager) and the Okta Identity Cloud. This initial integration allowed you to validate if a device was trusted during an Okta application sign-on policy. 

Although this integration has been widely adopted and successful, there were a few limitations, most notably:

• Lack of support for enforcing Device Trust on Windows 10 and macOS on the Okta Application Sign-On Policy
• Inability to leverage a Device Compliance authentication method in Workspace ONE Access 

As part of the on-going partnership with VMware and Okta, we are working on a long-term vision for a more in-depth integration which includes sharing more device, application, and identity context between the two platforms. This integration will be focused on Okta’s new Identity Engine Platform.

In the meantime, VMware and Okta are offering Factor-Based Device Trust. With Factor-Based Device Trust, we are addressing some of the core gaps that are present in the existing integration. Factor-Based Device Trust will support Win10, macOS, Android, and IOS. This offering will also allow you to specify a Device Compliance authentication method in Workspace ONE Access. 

Switching to Factor-Based Device Trust is not required for customers using the current integration if it meets their needs. The existing integration will continue to be supported by both companies. Customers can remain on the existing version of device trust and switch to the next evolution of device trust when it’s ready on the Okta Identity Engine. 

Factor-Based Device Trust is based on a completely different design and does not use the built-in Device Trust flags in Okta. This version will support:

• IOS, Android, Win10, macOS
• Using a Device Compliance Authentication Method in Workspace ONE Access
• Okta Routing Rules
• Okta Username/Password
• Okta Verify for Unmanaged Devices
• Enforcing a Device Trust validation on multiple application launches

This version of device trust is based on an MFA Framework.

Note: There is a change to the user experience in this flow. The users will have to click Verify. Unfortunately, there is currently no support for auto push. However, displaying the prompt will allow users to select an alternate MFA for unmanaged applications. We’ll talk more about this later in this blog.

Without Routing Rules:

With Routing Rules:

Using a new capability in Okta called IdP Factor, Workspace ONE Access can be invoked like any other MFA solution. At a high level, Okta will trigger a SAML Authentication Request to Workspace ONE Access in the Application Sign-On Policy.

In Workspace ONE Access, a Mobile SSO/Certificate + Device Compliance policy will ensure the device is Managed and Compliant and send the response back. If the device is not compliant, a customizable error message will be displayed in Workspace ONE Access. 

In your Okta Factor Enrollment Policy, you will specify which applications will use the Workspace ONE Factor ONLY. For applications that you want to allow unmanaged device access, your factor enrollment policy will allow for a choice of Workspace ONE Access or another factor such as Okta Verify. 

Before we walk through the steps to get this all set up, let’s go through some frequently asked questions:

If I currently have Device Trust configured for IOS and Android, do I need to switch to Factor-Based Device Trust?
No, you can continue to use the existing version of the device trust. 

Can I use the existing version of device trust for IOS and Android and use this new method for Win10 and macOS?
Yes, both methods can be used simultaneously. If you are using routing rules, a separate routing will need to be created for Win10 and macOS which does not send the device trust authentication context. 

Will both options be fully supported by VMware and Okta?
Yes, both options will continue to be supported by both companies. 

Getting Started

The following sequence is covered below:

1. Requirements
2. Creating a Workspace ONE Access ONE Identity Provider in Okta
3. Configuring IdP Factor
4. Factor Enrollment Policies
   1. Applications that ONLY allow IdP Factor
   2. Applications that Support Device Trust but Allow Un-Managed Access with MFA
   3. Default Enrollment Policy
5. Creating your Okta Application in Workspace ONE Access
   1. Download Okta Metadata
   2. Configure Workspace ONE Access
6. Configuring Workspace ONE Access Policies
   1. Assigning Access Policies
7. Configure Okta Application Sign-On Policies
8. Configuring Routing Rules
   1. Create Workspace ONE Access “Okta” Application
9. Troubleshooting

Requirements

In order to use Factor-Based Device Trust, you will need to get IdP Factor enabled in your Okta Tenant. To get this early access feature enabled, you will need to contact Okta Support and ask them to enable the features CLAIMS_AS_FACTOR and MFA_ENROLL_POLICY_APP_CONDITION. Once these are enabled, you should see a new Factor Type called IdP Factor in Security > Multifactor.

Note: Please make sure you have the appropriate licenses to access this feature. Please contact your Okta Sales Representative more information around licenses.

Creating a Workspace ONE Access ONE Identity Provider in Okta

If you are currently using the existing Device Trust integration or using Routing Rules, you’ve probably already created an Identity Provider instance in Security > Identity Providers for Workspace ONE Access. However, in order to use Factor-Based Device Trust, you will need to create a new Identity Provider instance:

1. Go to Security > Identity in the Okta Administrative Console.
2. Click Add Identity Provider > Add SAML 2.0 IDP.
3. Provide a name for this identity provider. Please note that this name will be displayed on the MFA Prompt.
   

4. For IdP Usage, select Factor only.
   

5. Under SAML Protocol Settings, click Add Identity Provider.

Configuring IdP Factor

1. Go to Security > Multifactor > IdP Factor.
2. Click Edit.
3. Select the Identity Provider you created in the previous step. You will get an error if you select an Identity Provider configured for SSO Only.
4. Click Save.
5. Activate IdP Factor by selecting Activate in the top right.
   

Factor Enrollment Policies

In order to ensure that IdP Factor cannot be bypassed by another enabled Factor in Okta, we need to configure Factor Enrollment Policies. The Factor Enrollment Policies will control which factors can be used for specific applications. We’ll cover this section into three categories:

• Applications that ONLY allow IdP Factor (Device Trust strictly enforced)
• Applications that support IdP Factor but will allow another factor such as Okta Verify (Support for Unmanaged Devices)
• Default Enrollment Policy

Applications that ONLY allow IdP Factor

1. In Security > Multifactor, click Factor Enrollment.
2. Click Add Multifactor Policy.
3. Provide a Policy Name.
4. Assign this to the applicable groups.
5. Set IdP Factor as Required and Disable all other factors.
   

6. Click Create Policy.
7. Provide a Rule name, i.e., Check WS1.
8. Select the application checkbox.
9. Select Specific Applications.
10. Choose all the applications you want to enforce device trust only.
    

11. Click Create Rule.

Applications that Support Device Trust but Allow Un-Managed Access with MFA

In the previous version of Device Trust, we would check device trust first and if that fails, we would enforce an MFA challenge. With Factor-Based Device Trust, for unmanaged devices, the users will have a choice up front to use another factor:

1. Create a Multifactor Policy similar to the previous section.
2. Select all the applicable factors as Optional.
   

3. Click Create Policy.
4. Provide a Rule Name and Selection that the applicable applications.
5. Click Create Rule.

Default Enrollment Policy

With Multifactor Authentication, there is a concept of enrolling your MFA with Okta. Please don’t confuse this with Device Enrollment. When a user uses Factor-Based Device Trust for the first time, they will be prompted to enroll into the factor. Essentially, the user will be re-directed to Workspace ONE Access and authenticated via Certificate Authentication (or Mobile SSO). Upon successful return to Okta, the user will be enrolled into the factor. The user will ONLY need to do this once. They will NOT have to repeat this for each device. This is only linking IdP Factor with Workspace ONE Access. When prompted during authentication, Workspace ONE Access will validate each device for compliance at that time.

1. Navigate to Security > Multifactor > Factor Enrollment.
2. Update your Default Policy and include IdP Factor as optional.
   

Creating your Okta Application in Workspace ONE Access

Download Okta Metadata

1. In the Okta Administration Console, download your metadata for the new Factor Only IdP we created in the previous steps.
2. In Security > Identity Providers, expand your IdP.
   
3. Click Download Metadata.

Configure Workspace ONE Access

If you are familiar with the previous VMware/Okta Integrations, we used the Okta Application Source for both Routing Rules and Device Trust. In this integration, we may have multiple Identity Provider instances configured in Okta:

• Identity Provider for “Factor Only” – IdP Factor
• Identity Provider for “SSO Only” – Routing Rules
• Identity Provider for “Device Trust” – Original Device Trust (iOS/Android)

Note: Every Identity Provider instance in Okta has a unique entityID and will require a separate configuration in Workspace ONE Access. I will do my best to explain how this is represented in Workspace ONE Access.

In Workspace ONE Access, we have a concept of an application source. An application source is simply a way of using a SAML configuration as an application type. This was introduced as a way to simplify the process when creating multiple SAML applications for the purpose of IdP Initiated (WS1) application launches (instead of copying an application multiple times with different relay states).

There is no functional difference between an application source and a regular SAML application in Workspace ONE Access. There is one exception though when it comes to the Okta integration. If you are using the dynamic integration for displaying Okta applications in Workspace ONE, it will use the application source to formulate the SAML response to Okta.

A Factor Only IdP instance in Okta, as the name implies, cannot be used for SSO. For this reason, I do NOT recommend using the application source for this configuration.

1. In Workspace ONE Access, go to Identity & Access Management > Catalog > Web Apps.
2. Click New.
3. Provide a Name, i.e., Okta Factor-Based Device Trust.
   

4. Click Next.
5. Paste the Metadata you previously download.
   

6. Click Next.
7. If you have an Okta Policy, select it. If not, we’ll create one in the next section.
   

8. Click Next.
9. Click Save & Assign.
10. Search for the All Users group and select it.
    

11. Click Save.
12. Now that the application is created, we will need to make a few changes. Select the Okta Factor-Based Device Trust application and click Edit.
13. Click Next.
14. Update the Username Value so it matches the correct format of users created in Okta.
    

15. Click Advanced Properties.
16. Update the Signature Algorithm and Digest Algorithm to SHA256.
    
    Note: Do NOT change any of the other advanced properties.

17. Scroll down and select Show in User Portal to No.
    

18. Click Next, Next, and Save.

Configuring Workspace ONE Access Policies

When creating your Workspace ONE Access policies, it is generally a good practice to add a new policy for the Okta Integration (and not use the default policy).

If you already have a policy for Okta, you can edit the existing policy rather than creating a new one.

1. Click Identity & Access Management > Policies.
2. Click Add Policy.
3. Provide a Name i.e., Okta Policy.
4. You can skip the Applies to section for now, and click Next.
5. Click Add Policy Rule.
6. Add each applicable platform policy based on your requirements (i.e., macOS, Win10, iOS, Android, etc.).
7. As we mentioned previously, Factor-Based Device Trust will allow you to use a combination of Certificate + Device Compliance (or Mobile SSO + Device Compliance).
   

8. Expand the Advanced Properties. When you use Factor-Based Device Trust, if the Authentication or Device Compliance fails, an error will be displayed to the user in Workspace ONE Access (and not sent back to Okta). You can customize the error in the fields provided:
   

9. Save the policy rule and repeat for each additional device platform as required.
10. Click Next and Save.

Assigning Access Policies

You can assign the access policy in two ways:

1. Edit the Access Policy and use the Applies to section. You search for each of the applications you’ve created. (Note: The Okta Application Source is called OKTA.)
   

2. Edit each Catalog item (or Application Source) and select the Access Policy:
   

Configure Okta Application Sign-On Policies

1. In Okta, search for your application and click the Sign-On tab.
2. Scroll down to the Sign On Policy.
3. Click Add Rule.
4. Provide a Name.
5. Select the appropriate People, Locations, and Clients.
   

6. Under Device Trust, select Any. 
   Remember: Factor-Based Device Trust does not use the internal Okta flags that denote a trusted device. It completely relies on Workspace ONE Access for Device Trust + Compliance.
   

7. Under Actions, select Prompt for factor, and chose the applicable frequency on how often you want to check for device check compliance.
   

8. Click Save and order the priority of the rule appropriately.

Configuring Routing Rules

Okta routing rules help to provide an optimal Passwordless user experience by enabling the ability to include Mobile SSO (iOS/Android) or Certificate Auth (macOS/Win10) for SP initiated authentication requests. However, it is not a requirement if you don’t want to use it.

To get started using routing rules, you will need to create an Identity Provider instance. As mentioned earlier, you cannot use the Factor Only identity provider instance that you previously created.

1. Go to Security > Identity in the Okta Administrative Console.
2. Click Add Identity Provider > Add SAML 2.0 IDP.
3. Provide a name for this identity provider.
4. For IdP Usage, select SSO only.
5. For IdP Username, select idpuser.subjectNameId.
6. For If no match is found, select Redirect to Okta sign-on page.
   

7. Under SAML Protocol Settings, expand Advanced Settings.

8. IdP Issuer URI	https://<TenantURL>/SAAS/API/1.0/GET/metadata/idp.xml i.e., https://dsas.vidmpreview.com/SAAS/API/1.0/GET/metadata/idp.xml
   IdP Single Sign-On URL	https://<TenantURL>/SAAS/auth/federation/sso i.e., https://dsas.vidmpreview.com/SAAS/auth/federation/sso
   IdP Signature Certificate	Click Browse and Select your Workspace ONE Access Signing Certificate. If you don’t have your signing certificate: 1. In Workspace ONE Access, go to Catalog > Webapps > Settings. 2. Click SAML Metadata. 3. Download Signing Certificate.

    

8. Make sure Request Binding is set to HTTP POST.
9. Make sure Request Authentication Context is set to NONE.
   

11. Click Add Identity Provider.
12. Click the Routing Rules Tab.
    

13. Click Add Rule.
14. Provide a Rule Name.
15. Select the Platforms.
16. Select the Applications.
17. Select the Identity Provider instance you just created.
18. Click Create Rule.
    
19. Don’t Activate the Rule yet.

Create Workspace ONE Access “Okta” Application

To support authentication requests coming from the routing rule in Workspace ONE Access, we will need a matching Catalog Item or Okta Application Source.

1. Download your metadata in Okta for this new Identity Provider instance similar to how we did it previously.
2. In you are not using the Okta Application Source (for older iOS/Android Device Trust that is using an Okta Identity Provider instance sending Device Trust SAML Context), you can configure it for use with routing rules. If you are currently using the application source, then you will need to create a new application.
   1. Application Source
      1. Go to Catalog > Web Apps > Settings.
      2. Click Application Sources.
      3. Click Okta.
      4. Click Next.
   2. Catalog Item
      1. Go to Catalog > Web Apps.
      2. Click New.
      3. Provide a Name i.e., Okta Routing Rules.
      4. Click Next.
3. Paste the previously downloaded Okta Metadata.
4. Click Next.
5. Select the Okta Access Policy.
6. Click Save.
7. Now that the application is created, we will need make a few changes. Select the Okta Routing Rules  application and click Edit.
8. Click Next.
9. Update the Username Value so it matches the correct format of users created in Okta.
   

10. Click Advanced Properties.
11. Update the Signature Algorithm and Digest Algorithm to SHA256.

    Note: Do NOT change any of the other advanced properties.

12. Scroll down and select Show in User Portal to No.
13. Click Next, Next, and Save.
14. If you used a Catalog Item (and not the Application Source), you will need to assign the application:
    1. Select the Application and click Assign.
    2. Search for the All Users group and select it.
    3. Click Save.
15. You can now Activate your Routing Rule in Okta.

Troubleshooting

Here are some high-level steps to ensure your configuration is set up correctly. I will update my troubleshooting blog with helpful tips as they arise. https://theidentityguy.ca/2020/11/10/workspace-one-and-okta-troubleshooting-blog/

Note: There is a known issue in Okta, that after enabling Factor-Based Device Trust (or Factor Sequencing) you may receive a 404 error using the older device trust. Okta is currently working on a fix for this issue. If you want to back out Factor-Based Device Trust, you will need to remove the features specified in this blog and ask Okta Support to remove STATE_TOKEN_ALL_FLOWS.

Under Dashboard > Reports > Audit Events:

If you are using Routing Rules, you should have an event that maps the SAML_REQUEST to either the Okta Application Source or the Catalog Item.

Verify that Certificate Authentication (or Mobile SSO) Correct Maps to the right user.

Verify that Factor-Based Device Trust maps to the correct object: