Skip navigation

So in the latest integration between Workspace ONE Access (aka. VMware Identity Manager) and Okta, we've added the device trust capabilities into the Okta Administration Portals.  I've noticed there has been some confusion on what this integration really does and why it's been added to the solution.


Which method should you use? In order to determine which method you should use we need to look at both options.


Lets walk through how the process worked previously:


  1. User goes to a SaaS Application
  2. The SaaS application will redirect the user to Okta
  3. Okta Routing Rules will proxy the SAML Authentication request to Workspace ONE access based on the predefined rules.
  4. Workspace ONE Access will determine if the device is managed (based on Mobile SSO/Certificate) and if the device is compliant (based on the enrolment in Workspace ONE UEM)
    1. If the device meets correct conditions (both Managed and Compliant) it will send a SAML Authentication Response back to Okta where any additional sign-on policies will be triggered and the user will be returned to the SaaS application.
    2. If the device does not meet the correct conditions (both Managed and Compliant) the user will most likely be displayed an "Access Denied" error with any appropriate "Compliance" messaging.

The benefit of this option is that it can provide a detailed explanation of why the authentication failed. We can also configure Workspace ONE Access to integrate with an MFA solution to step up the authentication.  The downside of using the existing method is that you need to configure authentication policies in both systems and the action to deny or MFA will apply to all application that Okta is routing to Workspace ONE Access.


Configuring Okta Device Trust


In the on going partnership between VMware and Okta, the strategy is to offload the authentication to Okta. This provides a strong value in configuring authentication policies in just one place.


Once you configure device trust in Okta, you have the ability to configure sign-on policies on a per app basis. This provides a lot of value as there are some applications that you would want to straight out deny access and some that might be okay as long as we did a step up authentication.


If you have configured a policy to DENY access, the user will be presented with the below message. They will have the ability to secure their device by enrolling in Workspace ONE UEM.


Let's walk through the steps required to set this up and we'll look under the covers of what is happening during the SAML exchange between the two systems.


First lets start in the Okta Portal,


First you need to enable Device Trust. Under Security -> Device Trust, click EDIT for either IOS or Android.

  1. Enable IOS Device Trust
  2. Select "VMware"
  3. Select "SAML-based (Workspace ONE UEM + vIDM)
  4. Click Next
  5. Select the correct Identity Provider
  6. Provide a name such as "Workspace ONE"
  7. Enter either your Web Enrolment Link or a linked to the appropriate app store to download the Workspace ONE Intelligent Hub.
  8. Click Save


Now we can modify our sign-on policies for our applications. In your application specific sign-on policy, add a rule for either "IOS/Android" and select your appropriate device trust option and the correct action (DENY or MFA).


Finally, we have to configure the Identity Provider to send the correct flags to Workspace ONE Access in order to trigger the Device Trust.


In Security -> Identity Providers, you need to enable the Device Trust Authentication Context.  (Note: This is under Advanced Settings). I'll explain shortly what this option is doing.



Configuring Workspace ONE Access for Okta Device Trust


We have to modify a couple setting in our Okta Application Source in order to support Okta Device Trust.


  1. Edit your Okta Application Source
  2. Under Configuration, expand Advanced Properties
  3. Enable Device SSO Response
  4. Enable Force AuthN Request. This setting will allow Workspace ONE to accept an ForceAuthN in a SAML AuthN request and process the Device Trust Authentication Context. There are some implications of enabling this setting. We'll discuss those later.
  5. Enable the Authentication Failure Notification. This setting will send a failure notification to Okta instead of display an error message on the Workspace ONE Access side.
  6. Click Next, Next, Save.


Understanding the SAML Exchange


When you make the changes above, the SAML messages between the two systems are modified.


When you configure the "Device Trust" authentication context in Okta, it will set a ForceAuthn flag = "True" in the AuthN request.


It will also add a device trust Authentication Context to the request:


Workspace ONE Access will respond to Okta with the Authentication Class Reference that was used to authenticate the user along with the Device Posture Check.  The Post Check returned will tell Okta whether the device is currently managed:



Implications of ForceAuthn


There are some important implications when using ForceAuthN in the Authentication Request.  There are some Authentication Methods that are not supported. The most prominent ones are "Device Compliance" and your 3rd Party IDP authentication methods.


If you are using the Okta Device Trust, this means that you can NOT use the "Device Compliance" authentication method in Workspace ONE Access.



Device Compliance vs Device Posture


This is a very important distinction and might have an impact on which option your chose to enable Device Trust. In the current implementation (configuring Mobile SSO/Cert + Device Compliance) in Workspace ONE Access, it will validate that the device is managed and it will check the compliancy of the device in Workspace ONE UEM.  In the initial release of Okta Device Trust, it will only check if the device is managed. Although this might seem like a big omission on the first release, depending on your compliance policies, you can imply that if a device is not compliant it will fail the posture check. (Removing MobileSSO profile on non-compliance).


Windows 10 and MacOS


In the first release of Okta Device Trust for Workspace ONE, they provided support for IOS and Android only. If you want Device Trust for Windows 10 and MacOS, you need to use the current method of configuring Cert + Device Compliance in Workspace ONE Access.

For updates on this blog and other blogs, follow me on Twitter: @SteveIDM


In the third installment of the Okta Integration with Workspace ONE, we are going to cover SCIM Provisioning from Okta to Workspace ONE.


NOTE: This integration requires UEM 19.09 which should be deployed to most SAAS tenants.


These instructions will use a "CUSTOM" SCIM application. I will update this blog when the official WS1 application is released in OIN.


Please do not use in Production.


In the first release of this functionality, there will be a lot of manual steps. I fully expect a more seamless process in future releases.


This process will require some proficiency and knowledge in using Postman to manage identities in Workspace ONE Access (formerly known as VMware Identity Manager).  Please check out my blog on using Postman to Manage Workspace ONE Identities.

Here is a high level overview of the process:

Screen Shot 10-15-19 at 11.44 AM.PNG

  1. Okta is configured to use Workspace ONE Provisioning Application
  2. Okta will SCIM the user to Workspace ONE Access
  3. The AirWatch Provisioning Adapter in Workspace ONE Access will provision the user to Workspace ONE UEM.


This blog will not going into detail on the provisioning to UEM. Please see the following blog on provisioning to UEM:

Workspace ONE - AirWatch Provisioning App

Step 1:  Create a Remote App Access Client

  1. Log into Workspace ONE Access
  2. Click on Catalog (Down Arrow) and then Settings
  3. Click on Remote App Access
  4. Click Create Client
  5. Select "Service Client Token"
  6. Enter a Client ID ie. OktaSCIM
  7. Expand Advanced
  8. Click Generate Shared Secret
  9. Update the Access Token TTL to something longer then the default. Note: If you choose 1 year, you will need to update the Okta configuration every year with a new bearer token.

  10. Copy the shared secret. You will need this later.
  11. Click Add


Step 2:  Configure Postman to use your OAuth Token


Note: Depending on your version of Postman, these steps below might be slightly different.


  1. Open a new Tab in Postman
  2. In the authorization section, select "OAuth 2.0" as the type:
  3. Click Get New Access Token
  4. Provide a Token Name (ie. Workspace ONE)
  5. Under Grant Type, select "Client Credentials"
  6. "Under Access Token URL", enter https:[Tenant URL]/SAAS/auth/oauthtoken
  7. ie.
  8. Under Client ID, enter your Client ID from step 1.
  9. Under Secret, enter your secret from step 1.
  10. Under Scope, enter 'admin'
  11. Click Request Token
  12. On the left hand side, Select "Request Headers" and click "Preview Request".

  13. You should see a message saying headers were updated correctly:
  14. Click the Headers Tab and verify that the bearer token was added as a temporary header.
  15. If the bearer token was not added, return to the Authorization Tab and select your token from the available tokens drop down list and preview the request again.


Step 3:  Create an "Other" Directory for your Okta Users.

  1. Open a new Tab in Postman
  2. Add the Authorization Header as per the previous section.
  3. For the HTTP Method, select "POST"
  4. For the URL, enter: https://[TENANTURL]/SAAS/jersey/manager/api/connectormanagement/directoryconfigs
    Replace the Tenant URL with your URL
  5. Under "Headers", Set the Content-Type to "application/"
    Screen Shot 10-15-19 at 11.49 AM.PNG
  6. Use the following as a sample and Click Send


"name":"Okta Universal Directory"  


You should see a similar result

Screen Shot 10-15-19 at 11.50 AM.PNG


Step 4:  Add the Workspace ONE SCIM Provisioning App in Okta


At the time of writing this blog, the Workspace ONE Provisioning APP is not published on the OIN.


In the meanwhile, I will document the steps to create on manually.

  1. Log into the Okta Admin Console
  2. Click on Applications -> Applications
  3. Search for the "SCIM 1.1 Test App (OAuth Bearer Token)" application
  4. Provide a Name for the application and check both "Do not display" checkboxes
    Screen Shot 10-15-19 at 11.52 AM.PNG
  5. Click Next
  6. Click Done
  7. Click on Sign On
  8. Under application format, select Email prefix
    Note: This step is required to avoid an issue with using email addresses as usernames when deploying SCEP certificates in Workspace ONE UEM.
  9. Screen Shot 10-15-19 at 11.53 AM.PNG
  10. Click on the Provisiong Tab and Click Configure API IntegrationClick Enable API Integration
  11. Enter the SCIM 1.1 Base URL in the following format: https://[tenant url]/SAAS/jersey/manager/api/scim
  12. Paste your bearer token that was created in the earlier step with postman.
  13. Click Test API Credentials
  14. Ensure you have a "Success" before proceeding.
  15. Click Save
  16. Scroll down to the Attribute Mapping Section
  17. Delete the following attributes
  18. Click "Go to Profile Editor"
  19. Click "Add Attribute"
    1. Enter "internalUserType" as the Display name, Variable Name and External Name
    2. Enter "urn:scim:schemas:extension:workspace:1.0" as the External Namespace
    3. Save
  20. Click Add Attribute
    1. Enter "userPrincipalName" as the Display name, Variable Name and External Name
    2. Enter "urn:scim:schemas:extension:workspace:1.0" as the External Namespace
    3. Save
  21. Click Add Attribute
    1. Enter "domain" as the Display name, Variable Name and External Name
    2. Enter "urn:scim:schemas:extension:workspace:1.0" as the External Namespace
    3. Save
  22. Click on Mappings
  23. Click on the Okta to Workspace ONE SCIM Tab
  24. Scroll  down to the new attributes we created and map the attributes as per below:
    Okta User ProfileWorkspace ONE SCIM User Profile
    Enter the Domain Used in Step 3domain
    Screen Shot 10-15-19 at 11.59 AM.PNG
  25. Remove the mappings (Mappings -> Okta to Scim 1.1):

  26. Click Save Mappings
  27. Click Apply Updates Now
  28. Click on the Provisioning Tab again
  29. Click Edit and Enable Provisioning for Create Users and Deactivate Users. Note: Do not select update users
  30. Click Save
  31. Using a test user, assign the user the Workspace ONE SCIM application
  32. If you receive an error such as below you might need to un-map additional attributes.


Issues with Groups

It has been discovered that there are a few issues with provisioning groups from Okta to Workspace ONE. While we wait for these issues to be resolved, you will need to pre-create the groups in Workspace ONE Access before they can be sync'd from Okta.


The following instructions require you to use Postman. You will not be able to do this from the Workspace ONE Access console.

  1. Open a new tab in Postman
  2. Add the Authorization Header as per the previous section.
  3. For the HTTP Method, select "POST"
  5. Replace the Tenant URL with your URL
  6. Under "Headers", Set the Content-Type to " APPLICATION/JSON"
  7. Use the following as a sample and Send. You will need to do this for each group you plan on linking in Okta: Replace the DisplayName with the same name as the group in Okta.


  "SCHEMAS": [  


Next we will need to "LINK" the groups in Okta:


  1. In the VMware Workspace ONE application (your SCIM 1.1 app) in the Okta console, click on “Push Groups”
  2. Click on Refresh App Groups to ensure Okta has a complete list of groups in Workspace ONE Access.
  3. Click on Push Groups -> Find Groups by Name
  4. Enter the name of the group that is already created in Okta
  5. Ensure that a match is found in Workspace ONE Access with the option to Link Group:

  6. Click Save


For additional troubleshooting see: