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 setup, 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

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 this is 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.
  1. For IdP Usage, select “Factor only”
  1. Under SAML Protocol Settings.
IdP Issuer URIhttps://TenantURL/SAAS/API/1.0/GET/metadata/idp.xml
ie. https://dsas.vidmpreview.com/SAAS/API/1.0/GET/metadata/idp.xml
IdP Single Sign-On URL 
https://TenantURL/SAAS/auth/federation/sso
ie.
https://dsas.vidmpreview.com/SAAS/auth/federation/sso
IdP Signature CertificateClick 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 on SAML Metadata
3. Download Signing Certificate
  1. 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 can not 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)
  • Application 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 on “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.
  1. Click Create Policy
  2. Provide a Rule name. ie. Check WS1
  3. Select the applications checkbox
  4. Select “Specific Applications”
  5. Choose all the applications you want to enforce device trust only.
  1. 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 an Multifactor Policy similar to the previous section.
  2. Select all the applicable factors as “Optional”
  1. Click Create Policy
  2. Provide a Rule Name and Selection that the applicable applications.
  3. 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. In Security -> Multifactor -> Factor Enrollment
  2. Update your Default Policy and to 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.
    1. In Security -> Identity Providers, expand your IdP
    2. 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, can not 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 ie. Okta Factor-Based Device Trust
  1. Click Next
  2. Paste the Metadata you previously download
  1. Click Next
  2. If you have an Okta Policy, select it. If not we’ll create one in the next section.
  1. Click Next
  2. Click Save & Assign
  3. Search for the “All Users” group and select it.
  1. Click Save
  2. 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.
  3. Click Next
  4. Update the “Username Value” so it matches the correct format of users created in Okta.
  1. Click Advanced Properties
  2. Update the Signature Algorithm and Digest Algorithm to SHA256

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

  1. Scroll down and select “Show in User Portal” to No
  1. 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 on Identity & Access Management -> Policies
  2. Click Add Policy
  3. Provide a Name ie. Okta Policy
  4. You can skip the “Applies to” section for now, Click Next.
  5. Click Add Policy Rule
  6. Add each applicable platform policy based on your requirements (ie. 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)
  1. 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:
  1. Save the policy rule and repeat for each additional device platform as required.
  2. 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”)
  1. 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
  1. 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.
  1. Under Actions, select “Prompt for factor” and chose the applicable frequency on how often you want to check for device check compliance.
  1. 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, its 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 can not 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”.
  1. Under “SAML Protocol Settings”
IdP Issuer URIhttps://TenantURL/SAAS/API/1.0/GET/metadata/idp.xml
ie. https://dsas.vidmpreview.com/SAAS/API/1.0/GET/metadata/idp.xml
IdP Single Sign-On URL 
https://TenantURL/SAAS/auth/federation/sso
ie.
https://dsas.vidmpreview.com/SAAS/auth/federation/sso
IdP Signature CertificateClick 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 on SAML Metadata
3. Download Signing Certificate
  1. Expand Advanced Settings
  2. Make sure “Request Binding” is set to “HTTP POST”
  3. Make sure “Request Authentication Context” is set to “NONE”
  1. Click Add Identity Provider
  2. Click on the Routing Rules Tab
  1. Click Add Rule
  2. Provide a Rule Name
  3. Select the Platforms
  4. Select the Applications
  5. Select the Identity Provider instance you just created
  6. Click Create Rule
  1. 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. Catalog -> Web Apps -> Settings
      2. Click Application Sources
      3. Click Okta
      4. Click Next
    2. Catalog Item
      1. Catalog -> Web Apps
      2. Click New
      3. Provide a Name ie. 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.
  1. Click Advanced Properties
  2. Update the Signature Algorithm and Digest Algorithm to SHA256

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

  1. Scroll down and select “Show in User Portal” to No
  2. Click Next , Next and Save
  3. 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
  4. You can now Activate your Routing Rule in Okta.

Known Issues

  1. Factor-Based Device Trust is not supported as part of a Factor Sequencing Policy.
  2. Global MFA using Okta Verify for SP Initiated Authentication Flows is NOT SUPPORTED
  3. Okta Mobile is not supported
  4. Fallback Authentication methods to Okta (from Workspace ONE Access) may result in a double authentication prompt.

Troubleshooting

Here are some high level steps to ensure your configuration is setup 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/

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:


6 thoughts on “Introducing Factor-Based Device Trust with VMware and Okta

  1. Great writeup! My company isn’t on WS1 but I’m testing the “IdP Factor” with great success with a few different services that do device posture checks. Unfortunately, there doesn’t seem to be a good way to map specific applications to specific IdPs. Each of these IdPs are really individual apps (SAML 2.0 app configurations within the posture service) with their own settings assigned to them (require encryption, require a minimum OS version, etc.). It seems like the “IdP Factor” is capped at one IdP.

    The closest I’ve gotten to it is using routing rules and specifying the applications on each rule but that only works if the user is logged out and hits the app with an embed link. Once they have a session, they are free to access whatever they want. A no-go there! Any ideas or suggestions?

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s