Skip navigation
1 2 Previous Next

Steve's IDM Blog

17 posts

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

 

I've written several blogs on the Okta Integration with Workspace ONE and thought it would be best to consolidate troubleshooting in one place.

 

When you encounter an error, don't forget to look at Dashboard -> Reports and go to Audit Events in Workspace ONE Access.

 

Please bookmark this blog as I will update this blog as necessary.

 

 

Troubleshooting Overview

The most important element of troubleshooting SAML is to get a SAML Tracer! Currently I use SAML Chrome Panel but there are plenty of them available:

 

Make sure you enable the Incognito Mode!

In order to troubleshoot you have to understand the flow. Lets review the flow:

The SAML_REQUEST

The first step in the end to end flow is the SAML Request to Okta. This is pretty basic and not really much to troubleshoot here. If you have correctly configured the Routing Rules, you should of been redirected to Workspace ONE Access.

 

Take a look at the Audit Logs for Workspace ONE and make sure you see a SAML_REQUEST that is properly mapped to the the Okta Application Source:

 

What if you don't see a SAML_REQUEST? If you don't see a SAML_REQUEST, then you probably have a mistake in your Okta IDP Settings. Make sure your Issuer URI is the one that ends in idp.xml!

 

The Object

Okay, so you have the SAML_REQUEST but its not mapped to an object? Or perhaps the wrong object?

 

Make sure your application source for Okta in Workspace ONE properly maps to the Workspace ONE Access Identity Provider which is configured in Okta:

IDP Not Found??

So now you mapped the SAML_REQUEST to the correct object but you are seeing an IDP not found in the audit details. This is actually quite common and is a result of an incomplete configuration. Take a look at your (built-in) Identity Provider in Workspace ONE Access where Mobile SSO is configured. Make sure your directory is checked off. If you created an "Other" directory for the SCIM integration it needs to be selected. Make sure that All Ranges is selected as well.

 

Okta Logon Page?

If you have configured Okta Device Trust for Workspace ONE, then this is the expected behavior if you are on a unmanaged device.

 

Okay, so what if everything mapped out correctly in Workspace ONE access but on the return to Okta you are seeing the logon page? If you look at the audit logs in Okta, you'll probably see something like:

This is probably because Workspace ONE Access is sending a username (ie. sAMAccountName) and Okta is expecting an email address or UPN.  If this is the case, edit your application source in Workspace ONE Access to send the correct username value:

 

 

 

Digital Workspace

You have configured Okta in Workspace ONE Access but you are not seeing the Okta applications in Workspace ONE?

It is likely that one of the three issues have occurred:

  1. Did you log into Workspace ONE Access as an end user? Okta Application will not appear in the Admin console.
  2. In the Okta Cloud URL  (Identity & Access Management -> Setup - Okta) , do not add the "-admin". It needs to be end user uri. ie. https://vmware.oktapreview.com
  3. Did you select the correct search parameter? In Workspace ONE Access, we typically have a sAMAccountName as the username (ie. jdoe) and in Okta, we typically have an email or UPN as the the username.  If this is the case, change the search parameter (Identity & Access Management -> Setup - Okta) to use email or upn.

 

Okta applications previously were showing in my Workspace ONE Catalog but are no longer appearing

If it has been 30 days since anyone in your tenant has accessed the Workspace ONE console, your Okta API key might have expired. Verify the key in Okta has not expired.

 

Identity Provider - Okta (3rd Party IDP)

You receive the error "federationArtifact.not.found Federation Artifact not found"

This error means the SAML context that Okta is sending is not currently defined in the 3rd Party IDP. In Workspace ONE Access, go to Identity & Access Management -> Identity Providers and modify the Okta Identity Provider to include the "Unspecified" SAML Context.

 

You receive the error "You do not have access to this service. Contact your administrator for assistance"

Verify the value being sent in the Name ID is properly configured to match a user in Workspace ONE Access. In Workspace ONE Access, go to Identity & Access Management -> Identity Providers and modify the Okta Identity Provider. Verify what the mapping is for "Unspecified". If the mapping is set to username, we might have a mismatch. Either check with a SAML Tracer or go to Dashboard -> Reports and go to Audit Events. Look for the "LOGIN failed ()" event and you'll see the username beside it. If you click on details, you will see something like "IDP (id: 541991) does not have JIT enabled when creating user (nameId: steve@one-identity.ca) " You have two options in the case:

  1. Modify the value in Identity & Access Management -> Identity Providers -> Okta Identity Provider so "Unspecified" is equal to Email or UserPrincipalName.
  2. Modify the Sign-On Policy for the Workspace ONE app in Okta to send the Email Prefix/Username Prefix

 

When you logout of Workspace ONE it will log you back in.

In the "VMware Workspace ONE" application in OKta, click on Sign-On and make sure Single Logout is enabled. You will have to upload your signing certificate from Workspace ONE Access. Once you have enabled this you will need to re-export the metadata and update the 3rd Party IDP in Workspace ONE Access. Don't forget to enable Single Logout Out (Keep the other two field blank).

 

Identity Provider - Workspace ONE (Routing Rules)

When using routing rules and after successfully authenticating with Workspace ONE you receive a 400 Error Code: GENERAL_NONSUCCESS

Verify in the 3rd Party IDP setting in Okta that you've configured the correct Issuer URI. It should end in "SAAS/API/1.0/GET/metadata/idp.xml"

 

When using routing rules and after successfully authenticating with Workspace ONE you receive an Okta Logon Page

In the Okta Application Source in Workspace ONE, make sure you are sending the correct value in the Username Value. In most cases, Workspace ONE usernames are sAMAccountName and will not match the username in Okta. You should change the value to either "${user.userPrincipalName}" or "${user.email}"

 

 

Device Trust

After successfully authenticating with Workspace ONE you receive a 400 Error Code: GENERAL_NONSUCCESS

Verify in the Identity Provider section in Okta that you the "Request Authentication Context" is set to "Device Trust"

 

On an non trusted device (Unmanaged) you receive the error "Kerberos NEGOTIATE failed or was cancelled by the user"

In Workspace ONE Access, edit the Okta Application Source (Catalog -> WebApps-> Settings -> Application Source), under Configuration - Advanced Properties, make sure Enable Authentication Failure Notification is set to Yes.

 

On a trusted device (Managed), you are stuck a loop between Okta and Workspace ONE Access

In Workspace ONE Access, edit the Okta Application Source (Catalog -> WebApps-> Settings -> Application Source), under Configuration - Advanced Properties, make sure Device SSO Response and Enabled ForceAuthN Request are both set to yes.

 

On a trusted device (Managed) you get an Okta Logon page with a "Device Must be Secured by Workspace ONE"

In the Workspace ONE policies, verify that you only have one authentication policy method for each platform. You can not use Mobile SSO + Device Compliance in a Workspace ONE Policy.

 

SCIM

You receive the error: “Errors reported by remote server: Required user attributes:[distinguishedName] are missing.”

You have the DN as a required attribute in Workspace ONE Access. You will need to uncheck this value in Identity & Access Management -> Setup -> User Attributes

 

You receive the error: “Errors reported by remote server: User creation is not supported for specified directory id”

You are attempting to create a user in a directory that is not of type “Other”. Verify when you completed the pre-requisites that you did not use a domain that is used by another directory. Its possible the domain was used for JIT. If this is the case you will need to create another directory of type other with a unique domain.

 

You receive the error: “Errors reported by remote server: User domain name specified for the user resource doesn't belong to the directory.”

The domain you configured in the attribute mapping in Okta does not match the domain for the directory created in Workspace ONE Access.

 

You receive the error “Errors reported by remote server: The group resource for create should not specify members.”

You need to create the users first in Workspace ONE using Postman and then link the group in Okta instead of Create.

 

You receive the error: “Errors reported by remote server: Resource 'Group' is malformed: Attribute urn:okta:custom:group:1.0:description is not defined for resource Group”

You need to create the users first in Workspace ONE using Postman and then link the group in Okta instead of Create.

In an earlier blog post,  I walked through various options on how to use Microsoft Authenticator with Workspace ONE Access (formerly known as VMware Identity Manager). In the final option, we talked about using the Microsoft Azure MFA Server.  However, as of July 1st, 2019, Microsoft is no longer offering the MFA Server for new deployments.

 

Microsoft does however provide another option to leverage Azure MFA by using the Network Policy Server extension for Azure.

 

In the blog I will walk through the process of configuring a Network Policy Server along with the NPS Extension.

 

 

 

Install and Configure the Network Policy Server

  1. Using the Server Manager -> Add Role and Features
    Screen Shot 09-25-19 at 01.42 PM.PNG
  2. Click Next
  3. Select Role-Based or feature-based Installation
  4. Select the Server from the Server Pool and click next
  5. Add the Network Policy and Access Services
    Screen Shot 09-25-19 at 01.43 PM.PNG
  6. Add the dependency features.
  7. Add the Network Policy Server
    Screen Shot 09-25-19 at 01.44 PM.PNG
  8. Complete the rest of the wizard to install the Network Policy Server.

 

Download and Install the NPS Extension

  1. Go to Download NPS Extension for Azure MFA from Official Microsoft Download Center
  2. Download the NPS Extension for Azure MFA Installer.
  3. Run the installer
    Screen Shot 09-25-19 at 01.49 PM 002.PNG
  4. Click Install

 

Configure the NPS Extension

  1. Run Windows Powershell as an Administrator
  2. At the powershell prompt, cd to "c:\Program Files\Microsoft\AzureMfa\Config"
  3. Run ".\AzureMfaNpsExtnConfigSetup.ps1"
  4. You will be prompted to authenticate with Azure.
  5. After successful authentication, you will be prompted to enter your tenant id. This is your Directory ID which can be copied from your Azure Console:
    directoryid.png
  6. This script will create a self signed certificate for you.

 

Configure your NPS Server

  1. Access your NPS Server (via Admin Tools)
  2. Under standard configuration, select "Radius server for Dial-up or VPN Connections"
  3. Click Configure VPN or Dial-up
  4. Select "Virtual Private Network (VPN) Connections"
  5. Provide a friendly name ie. Workspace ONE
  6. Click Next
  7. Under Radius Clients -> Click Add
  8. Provide a friendly Name, IP Address and a Shared Secret
  9. Click OK and Next
  10. Select Microsoft Encrypted Authentication version 2 (MS-CHAPv2)
  11. Click Next
  12. Under Groups, - Select a group that includes your MFA Users.
  13. Click Next for IP Filters
  14. Click Next for Encryption Settings
  15. Click Next for Realm Name (leave blank)
  16. Click Finish
  17. Click on Policies -> Connection Request Policies
  18. Double Click on the new "Workspace ONE Policy"
  19. Change the type to Unspecified
  20. Click on the Condition Tab
  21. Delete the NAS Port Type and Click Add
  22. Select "Access Client IPv4Address"
  23. Enter the IP Address of the Connector Server
  24. Click OK
  25. Click on Policies -> Network Policies
  26. Double Click on the new "Workspace ONE Policy"
  27. Change the Type to Unspecified
  28. Under Conditions, you should just have the group condition
  29. Under Constraints, select "Microsoft Encrypted Authentication version 2 (MS-CHAP-v2)"
  30. Click OK.

 

Configure Workspace ONE Access

  1. Log into your Workspace ONE Access Admin Console
  2. Go to Identity & Access Manager -> Setup
  3. Click on your Connector Worker -> Auth Adapters
    Screen Shot 10-14-19 at 04.17 PM.PNG
  4. Click on Radius Adapter
  5. Enter your Radius Host, Ports and Secret
    Note: Do not enter an accounting port.  I was not able to get this to work with the NPS Server.





  6. Select MSChapv2 as the encryption type.
  7. Click Save
  8. In the Workspace ONE Access Console, go to Identity Providers and edit the Built-In provider.
  9. Enable the Cloud Based Radius Adapter
  10. Click Save.
  11. You can now use the Cloud Radius Adapter in your Access Policies.

If you have read my previous blog on configuring Okta Device Trust for Workspace ONE you will know that Okta has not yet implemented device trust for Windows and MacOS. I also mentioned in the previous blog that if you want to leverage device trust for Windows and MacOS that you will need to use the original method with just routing rules.

 

In my previous blog I didn't go into the details on how you would configure device trust for both IOS/Android and Windows/MacOS. Its not really as straight forward as you would think because once you have configured an Identity Provider in Okta to use device trust, it will always send the device trust authentication context which will always result in an authentication failure for Windows and MacOS (assuming its being evaluated for Certificate and Device Compliance - AirWatch).

 

Note: This blog will not go into steps to configure Workspace ONE UEM or Workspace ONE Access to perform Certificate Based Authentication. We will assume that this has already been done.

 

There are a couple extra steps you will need to do.  Lets walk through the steps.

 

Create a New Identity Provider

 

First you will need to create another Identity Provider for Workspace ONE.

 

  1. Log into the Okta Administration Portal and go to Security -> Identity Providers
  2. Click Add Identity Provider -> Add SAML 2.0 IDP
  3. Configure this Identity Provider exactly as you've configured the previous one
  4. Click on Show Advanced Settings
  5. Make sure the Request Authentication Context is set to None
  6. Click Add Identity Provider
  7. Expand the Identity Provider you just created and download the metdata

 

Create a new Workspace ONE Application for Okta

 

  1. In Workspace ONE Access, got to Catalog and Click New
  2. Provide a name for this application (ie. Okta Device Trust for Windows/MacOS)
  3. Paste the metadata you downloaded in the previous step.
  4. Click Next, Next, Save
  5. Click Edit for the application you just created
  6. Click Configuration
  7. Modify to the username value to match the username format in Okta.
    Screen Shot 10-02-19 at 12.35 PM.PNG
  8. Click Access Policies
  9. Select the same policy you assigned to the Okta Application Source
    Screen Shot 10-02-19 at 12.36 PM.PNG
  10. Click Next - Save
  11. Assign the application to your users.
  12. Click on Identity and Access Management -> Policies
  13. Edit your Okta Policy
  14. Create a Policy Rule for MacOS to use Certificate and Device Compliance.
    Screen Shot 10-02-19 at 12.38 PM.PNG

 

Modify your Routing Rules in Okta

 

Finally, we can now add this new configuration into the routing rules in Okta

 

  1. Log into the Okta Admin Console
  2. Click on Security -> Identity Providers
  3. Click on Routing Rules
  4. Click Add Routing Rule
  5. Add a rule that will evaluate Windows and MacOS for your required applications and select the new "Workspace ONE - No Device Trust" identity provider we created in the first step.
    Screen Shot 10-02-19 at 12.52 PM.PNG
  6. Verify that there are no other rules that will take precedence over your newly created rule.

In this blog we are going to discuss adding Multi-Factor Authentication using Okta Verify with VMware Horizon by leveraging the Okta Radius Agent.

For more information on this integration, please see https://www.okta.com/integrations/mfa-for-virtual-desktops/vmware/

 

We are going to walk through 3 separate deployment options to leverage the Okta Radius Client:

 

  1. Using Workspace ONE Access (formerly known as VMware Identity Manager)
  2. Using Unified Access Gateway (UAG)
  3. Using Horizon Connection Servers

 

Let's start with installing and configuring the Okta Radius Agent.

 

Installing the Okta Radius Agent

For detailed instructions please see: https://help.okta.com/en/prod/Content/Topics/Directory/Agent_Installing_the_Okta_Radius_Agent.htm

 

  1. Download the Okta RADIUS Agent from the Okta Admin Portal by going to Settings -> Downloads
    Screen Shot 09-06-19 at 03.11 PM.PNG
  2. Once downloaded, launch the installer.
  3. On the intro screen, click next
  4. Click Next accept the license agreement:
  5. Select the correct installation patch and click Install.
  6. Create a Secret that will be used when configuring the radius clients.
    Screen Shot 09-06-19 at 03.13 PM 003b.png
  7. If you require a proxy complete this section otherwise click next
  8. Click Next
  9. Enter your tenant name (Note: Do not enter the full URL) with the appropriate instance
    Screen Shot 09-06-19 at 03.19 PM 001.PNG
  10. You will be redirected to your Okta tenant to Authenticate
    Screen Shot 09-06-19 at 03.19 PM.PNG
  11. Click Allow Access
    Screen Shot 09-06-19 at 03.20 PM.PNG
  12. You can then complete the installation.

 

Configure the Okta Radius Agent

 

The configuration for the Okta Radius Agent will be done within the Okta Admin Portal

 

  1. Click on Applications -> Applications
  2. Click New Application
  3. Search for "VMware Horizon View (RADIUS)" and Click Add
  4. Click Next
  5. Enter the UDP Port (1812)
  6. Enter the radius secret you used previously
  7. Select the correct username to match your environment.
    This is a very important step. For an optimal user experience, this should match your horizon credentials. If you have multiple AD domains in your horizon environment this should include the domain (ie. UPN or EMAIL).
  8. Click Done
  9. Click on the VMware Horizon View (RADIUS) application.
  10. Click Edit for the Advanced Radius Settings
  11. If you want to enable PUSH Notification, make sure the top two boxes are checked

 

Using Workspace ONE Access (formerly known as VMware Identity Manager)

 

  1. In the Workspace ONE Access Admin Console, go to Identity & Access Management -> Setup -> Connectors
  2. Click on your Worker to edit your connector configuration
  3. Click on Auth Adapters
  4. Click on the Radius Auth Adapter
  5. This will launch a configuration page running on your connector server.
    You will need connectivity to your connector server to complete this step.
    If you are presented an access denied page you might need to temporary change your policy to Password.
  6. Add your Radius Server Host name, Port and Shared Secret. (Leave the Authentication Type as PAP)
    Screen Shot 09-10-19 at 10.08 AM.PNG

  7. Click Save
  8. Return to the WS1 Access Admin Console and verify the Radius Auth Method is enabled. (You might need to refresh)
  9. Go to Identity & Access Management
  10. Click on Identity Providers
  11. Click on your Built-In Identity Provider
  12. Under Connector Authentication Methods, select Radius (Cloud Deployment)
  13. Click Save
  14. Click on Policies
  15. Edit your appropriate policy to include "Radius (cloud deployment)". In my example, I'm modifying the Win10 rule in the Default Policy.
    Screen Shot 09-10-19 at 10.15 AM.PNG
  16. Click Save, Next and Save.
  17. Open an Incognito Window and we'll test the configuration
    Note: If you ever lock yourself out, you can always go to: https://[TENANT].vmwareidentity.com/SAAS/auth/0 to login using your System Domain Account.
  18. You will be prompted to enter your Okta Credentials
  19. You should be prompted to approve the authentication on your Okta Verify Application
    Apowersoft_Screenshot_2019_09_10_13_30_12.jpg

Using Unified Access Gateway (UAG)

 

In environments where a Unified Access Gateway is deployed, most customers will typically want to configure MFA here as this appliance typically sits on the network edge. We can configure UAG to prompt for MFA using Okta Verify and then pass the credentials to Horizon to complete the authentication into the view client.

 

Note: If you have multiple AD domains, you will need to ensure your login through Okta contains the domain name (ie. UPN/Email).

 

  1. Log into your UAG Admin Console
  2. Under Authentication Settings, click the gear icon for RADIUS
  3. Enable RADIUS, Select PAP and enter the host name and port for the Okta Radius Agent.
  4. Click Save
  5. Expand Edge Service Settings and edit the Horizon Settings
  6. Click on "More" (at the bottom)
  7. Under Auth Methods, select radius-auth
  8. You will also need to enable "Enable Windows SSO" to prevent a subsequent login into the horizon client.
  9. Click Save
  10. Test your configuration by logging into the Horizon Portal. You will be prompted for your Okta username and password
    Screen Shot 09-10-19 at 02.09 PM.PNG
  11. You will then be prompted to approve the Okta Verify request on your device.

 

 

Using Horizon Connection Servers

 

Radius can be configured directly on the Horizon Connection Servers. This allows for MFA to be configured for both internal and external users (assuming internal users are not going through UAG).

 

Note: If you have multiple AD domains, you will need to ensure your login through Okta contains the domain name (ie. UPN/Email).

 

  1. Log into your Horizon Admin console
  2. Edit your Connection Server Settings
  3. Under Advanced Authentication, select Radius
  4. Select "Use the same username and password for RADIUS and Windows Authentication
  5. On the Authenticator drop down, select Create New Authenticator
  6. Enter your host name, port and secret for the Okta Radius Agent
    Screen Shot 09-10-19 at 01.41 PM.PNG
  7. Click OK
  8. Click OK.
  9. Test your configuration by logging into the Horizon Portal. You will be prompted for your Okta username and password
  10. You will then be prompted to approve the Okta Verify request on your device.

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.

https://communities.vmware.com/blogs/steveIDM/2019/05/09/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. https://dsas.vmwareidentity.com/SAAS/auth/oauthtoken
  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
    ie. https://dsas.vmwareidentity.com/SAAS/jersey/manager/api/connectormanagement/directoryconfigs
  5. Under "Headers", Set the Content-Type to "application/vnd.vmware.horizon.manager.connector.management.directory.other+json"
    Screen Shot 10-15-19 at 11.49 AM.PNG
  6. Use the following as a sample and Click Send

 

{  
"type":"OTHER_DIRECTORY",  
"domains":["Okta.com"],  
"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
    -entitlements
    -roles
  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
    'PROVISIONED'internalUserType
    user.emailuserPrincipalName
    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):

    Attributes
    displayName
    locale
    title
    department
    organization
  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"
  4. For the URL, enter: HTTPS://[TENANTURL]/SAAS/JERSEY/MANAGER/API/SCIM/GROUPS
  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": [  
    "URN:SCIM:SCHEMAS:CORE:1.0"
  ],  
  "DISPLAYNAME": "SCIMTESTING2"  
}

 

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:

https://communities.vmware.com/blogs/steveIDM/2019/10/21/workspace-one-and-okta-troubleshooting-blog

There are times during troubleshooting where you like to see a particular attribute in Workspace ONE Identity (VMware Identity Manager) and its not displayed in the web portal or times when you would like to update a particular attribute or delete a JIT user.

 

DISCLAIMER:  Please use the API with caution as this can potentially cause issues if not used appropriately. Please do NOT use in Production. Please use at your own risk.

 

In this blog we'll walk through a few useful API calls to help in your troubleshooting. For a complete list of API calls and documentation:

 

VMware Identity Manager API - VMware API Explorer - VMware {code}

 

Please download and install the latest version of Postman.

 

In this blog we'll go use the following API's:

  • Get Specific User Details
  • Update SCIM User
  • Delete SCIM User
  • Create SCIM User

 

Step 1: Getting your OAuth Token

 

In order do use the SCIM based API you need an OAuth token. I'm going to walk through two different ways of getting a token to use in your environment.

 

If you are going to access a particular environment quite often using postman I would suggest you go with Option 1. If its unlikely you will access a particular environment that often then you should go with Option 2.

 

Option 1: Creating an OAuth Application

  1. Log into Workspace ONE Identity Admin Console
  2. Click on the Catalog (down arrow) and select Settings
    Screen Shot 05-08-19 at 01.16 PM.PNG
  3. Click "Remote App Access"
  4. Click Create Client
    Screen Shot 05-08-19 at 01.18 PM.PNG
  5. Select "Service Access Token" from the Drop down menu
  6. Provide a Client ID ie. Postman
  7. Expand Advanced
  8. Click Generate Shared Secret (or provide one)
  9. Click Add
    Screen Shot 05-08-19 at 02.30 PM.PNG
  10. We will configure Postman in the next section.

 

Option 2: Using your browser cookies

 

  1. Make sure you have a way of accessing your browser cookies. I use a Chrome plugin called "Edit this cookie"
    Screen Shot 05-08-19 at 02.40 PM.PNG
  2. Log into your Workspace ONE Identity Admin Console
  3. Click the Cookie Icon in the chrome address bar
  4. Search for the "HZN" cookie
    Screen Shot 05-08-19 at 02.43 PM.PNG
  5. Copy the value for HZN.
  6. We will configure Postman in the next section.

 

Step 2: Configure Postman to use your OAuth Token

Depending which option you chose in the previous step, follow the instructions below to add your OAuth Token

 

Option 1: Creating an OAuth Application

  1. Open a new Tab in Postman
  2. In the authorization section, select "OAuth 2.0" as the type:
    Screen Shot 05-08-19 at 02.50 PM.PNG
  3. Click Get New Access Token
    Screen Shot 05-08-19 at 02.52 PM.PNG
  4. Provide a Token Name (ie. Workspace ONE)
  5. Under "Auth URL", enter https:[Tenant URL]/SAAS/auth/oauth2/authorize
    ie. https://dsas.vmwareidentity.com/SAAS/auth/oauth2/authorize
  6. "Under Access Token URL", enter https:[Tenant URL]/SAAS/auth/oauthtoken
    ie. https://dsas.vmwareidentity.com/SAAS/auth/oauthtoken
  7. Under Client ID, enter your Client ID from step 1.
  8. Under Secret, enter your secret from step 1.
  9. Under Scope, leave blank.
  10. Under Grant Type, select "Client Credentials"
    Screen Shot 05-08-19 at 02.58 PM.PNG
  11. Click Request Token
  12. Click on WorkspaceONE under Existing Tokens
  13. Select Use Token
    Screen Shot 05-08-19 at 03.00 PM.PNG
  14. If you click on the headers tab you will see the "Authorization" header has been added with the correct token.

 

Option 2: Using your browser cookies

 

  1. Open a new Tab in Postman
  2. Click on the Headers Section
  3. Add the Header Key "Authorization"
  4. In the Value, type "Bearer" then paste the value of the HZN cookie.
    Screen Shot 05-08-19 at 03.10 PM.PNG

 

Getting User Details

Now that you have your OAuth token, we can use this token to query Workspace ONE Identity.

 

  1. For the HTTP Method, select "GET"
  2. Enter the following for the URL: https://[TENANTURL]/SAAS/jersey/manager/api/scim/Users?filter=username%20eq%20%22MyUserID%22
  3. Replace MyUserID with a username in your environment
    ie. https://dsas.vmwareidentity.com/SAAS/jersey/manager/api/scim/Users?filter=username%20eq%20%22sdsa%22
  4. This will return a complete result set of attributes for the particular user.
    Screen Shot 05-08-19 at 03.23 PM.PNG

Updating User Details

In order to update user details via the API, you will need to collect some information from the Get User Details.

 

In my example, I'm going to update the "userPrincipalName" in Workspace ONE Access for one of my users.

  1. Perform a "Get" on the particular user and retrieve the schema information. Please note, this will be different for each tenant as the tenant name is part of the schema.
    Screen Shot 05-08-19 at 03.34 PM.PNG
  2. Copy this section to notepad.
  3. Retrieve the section which contains the attribute(s) you want to update
    Screen Shot 05-08-19 at 03.35 PM.PNG
  4. Copy the ID of the User
    Screen Shot 05-08-19 at 03.38 PM.PNG
  5. Open a new Tab in Postman
  6. Add the Authorization Header as per the previous section.
  7. For the HTTP Method, select "PATCH"
  8. For the URL, enter: https://[TENANTURL]/SAAS/jersey/manager/api/scim/Users/[ID]
    Replace the Tenant URL with your URL
    Replace the ID with the ID from the step 4 in this section.
    ie. https://dsas.vmwareidentity.com//SAAS/jersey/manager/api/scim/Users/884b7e7d-6a7b-4985-b113-56235826e8a6
  9. Select Body
  10. Enter the JSON in raw text that we'll post to Workspace ONE
  11. Select "JSON (application/json)" as the Content-Type
    Screen Shot 05-08-19 at 04.02 PM.PNG
  12. Click Send
  13. You should receive a "204 No Content" response
    Screen Shot 05-08-19 at 04.03 PM.PNG
  14. If you perform a GET User again you should see the value has changed.

 

Delete Users

If you are using JIT to onboard users into Workspace ONE Identity you've probably noticed there is no way to delete users in the web portal. They only way to delete is with the API.

  1. Perform a "Get" on the particular user and retrieve the ID
    Screen Shot 05-09-19 at 10.47 AM.PNG
  2. Open a new Tab in Postman
  3. Add the Authorization Header as per the previous section.
  4. For the HTTP Method, select "DELETE"
  5. For the URL, enter: https://[TENANTURL]/SAAS/jersey/manager/api/scim/Users/[ID]
    Replace the Tenant URL with your URL
    Replace the ID with the ID from the step 4 in this section.
    ie. https://dsas.vmwareidentity.com//SAAS/jersey/manager/api/scim/Users/f6f89782-0a2a-4cc8-84a8-057f1da6ecde
  6. Click Send
    Screen Shot 05-09-19 at 10.50 AM 001.PNG
  7. You should receive a "204 No Content" response
    Screen Shot 05-08-19 at 04.03 PM.PNG
  8. If you perform a GET User again you should see no results found.
    Screen Shot 05-09-19 at 10.53 AM.PNG

 

Create Users

Creating Users in Workspace ONE Identity require a lot more steps. I reluctantly decided to document the steps as this should really be done by the out of the box connectors. The process is slightly different between System Directory, Local Directory, and Other.  The "Other" directory is created automatically when setting up the UEM/WS1 Integration.

 

Creating Users in the System Directory

  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/scim/Users
    Replace the Tenant URL with your URL
    Replace the ID with the ID from the step 4 in this section.
    ie. https://dsas.vmwareidentity.com//SAAS/jersey/manager/api/scim/Users
  5. Set the Content-Type to "application/json"
  6. Use the following as a sample:
{
  "schemas": [
    "urn:scim:schemas:core:1.0",
    "urn:scim:schemas:extension:workspace:tenant:sva:1.0",
    "urn:scim:schemas:extension:workspace:1.0",
    "urn:scim:schemas:extension:enterprise:1.0"
  ],
  "userName": "testing4@mydomain.com",
  "name": {
    "givenName": "first4",
    "familyName": "last4"
  },
  "emails": [
    {
      "value": "testing4@mydomain.com"
    }
  ],
  "password": "Password$!"
}

 

Creating Users in a Local Directory

 

  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/scim/Users
    Replace the Tenant URL with your URL
    Replace the ID with the ID from the step 4 in this section.
    ie. https://dsas.vmwareidentity.com//SAAS/jersey/manager/api/scim/Users
  5. Set the Content-Type to "application/json"
  6. Use the following as a sample:
{
  "schemas": [
    "urn:scim:schemas:core:1.0",
    "urn:scim:schemas:extension:workspace:tenant:sva:1.0",
    "urn:scim:schemas:extension:workspace:1.0",
    "urn:scim:schemas:extension:enterprise:1.0"
  ],
  "userName": "testing5@mydomain.com",
  "name": {
    "givenName": "first5",
    "familyName": "last5"
  },
  "emails": [
    {
      "value": "testing5@mydomain.com"
    }
  ],
  "password": "Password$!",
   "urn:scim:schemas:extension:workspace:1.0": {
        "internalUserType": "LOCAL",
        "userStatus": "1",
        "domain": "mydomain.com"
      }


}

 

Creating Users in an Other Directory

 

The steps to create a user in an other directory is almost identity to the local directory except that we need to know the "userStoreUuid" of the directory and we need an ExternalID. The External ID should be a valid ObjectGUID. If you don't have a valid ObjectGUID you will have problems when enrolling devices from the Workspace ONE Intelligent Hub application. Ensure that you generate a proper guid. See Online UUID Generator Tool as a example of a proper guid.

 

  1. Open a new Tab in Postman
  2. Add the Authorization Header as per the previous section.
  3. For the HTTP Method, select "GET"
  4. For the URL, enter: https://[TENANT URL]/SAAS/jersey/manager/api/connectormanagement/directoryconfigs?includeJitDirectories=true
    Replace the Tenant URL with your URL
    Replace the ID with the ID from the step 4 in this section.
    ie. https://dsas.vmwareidentity.com/SAAS/jersey/manager/api/connectormanagement/directoryconfigs?includeJitDirectories=true
  5. Click Send
  6. In the response, search for your "Other Directory" and copy the userStoreID
  7. Screen Shot 05-09-19 at 05.25 PM.PNG
  8. Open a new Tab in Postman
  9. Add the Authorization Header as per the previous section.
  10. For the HTTP Method, select "POST"
  11. For the URL, enter: https://[TENANTURL]/SAAS/jersey/manager/api/scim/Users
    Replace the Tenant URL with your URL
    Replace the ID with the ID from the step 4 in this section.
    ie. https://dsas.vmwareidentity.com//SAAS/jersey/manager/api/scim/Users
  12. Set the Content-Type to "application/json"
  13. Use the following as a sample and don't forget to create a Unique External ID.
{
  "schemas": [
    "urn:scim:schemas:core:1.0",
    "urn:scim:schemas:extension:workspace:tenant:sva:1.0",
    "urn:scim:schemas:extension:workspace:1.0",
    "urn:scim:schemas:extension:enterprise:1.0"
  ],
  "externalId": "c58085e6-c97a-4df3-8e4a-e376913fab17",
  "userName": "testing6@mydomain.com",
  "name": {
    "givenName": "test6",
    "familyName": "last6"
  },
  "emails": [
    {
      "value": "testing6@mydomain.com"
    }
  ],
  "password": "Password$!",
   "urn:scim:schemas:extension:workspace:1.0": {
        "internalUserType": "PROVISIONED",
        "domain": "1dsavm.com",
        "userPrincipalName": "testing6@mydomain.com"
      }
}

 

Creating an Other Directory

When you configure UEM to integrate with Identity Manager an "Other" Directory should be automatically created. If in the case it is not created, you can create one via the API as well.

  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
    Replace the ID with the ID from the step 4 in this section.
    ie. https://dsas.vmwareidentity.com/SAAS/jersey/manager/api/connectormanagement/directoryconfigs
  5. Set the Content-Type to "application/vnd.vmware.horizon.manager.connector.management.directory.other+json"
  6. Use the following as a sample
{
"type":"OTHER_DIRECTORY",
"domains":["SteveTestDomain2"],
"name":"SteveTest2"
}

 

Troubleshooting

It would be impossible to discuss every combination of errors that can be returned using the API. Here are a few common ones:

 

  1. If you receive the error "User is not authorized to perform the task.".
    This error typically means that your Oauth Token has expired. Regenerate your OAuth Token.  If you have used the browser cookies method to get your token, ensure that your HZN cookie is from the administrative interface.
  2. When doing an update user, you receive the error ""???UNSUPPORTED_MEDIA_TYPE???""
    This error means that you are sending a blank or incorrect Content-Type. Check to make sure the content-type is set to "application/json"

The release of Workspace ONE 19.03 brought in a very seamless integration of Okta Applications.

 

If you have integrated the two solutions previously you will recall the number of steps required to create and entitle new applications in Workspace from Okta. This integrations you to create and entitle applications in Okta and have them seamless appear in Workspace ONE along with your Native and Virtual Applications.

 

Lets walk through the steps to integrate the two solutions.

 

In this blog we are going to assume that you have existing connectors for Workspace ONE UEM and Workspace ONE Identity. We are also assuming you have your Workspace ONE Identity access policies already configured for Mobile SSO, Certificate or Password (Cloud Deployment).

 

Part 2: Unified Digital Workspace

The objective of this section to automatically sync all SAML enabled applications from Okta to Workspace ONE. This configuration will eliminate the manual steps required to both create and entitle Okta applications in Workspace ONE.

 

Step 1: Create an Okta API Key

  1. Log into the Okta Admin Console
  2. Go to Security -> API
  3. Click on Tokens
    Screen Shot 05-08-19 at 10.32 AM.PNG
  4. Click Create Token
  5. Provide a name for the token
    Screen Shot 05-08-19 at 10.34 AM.PNG
  6. Click Create Token
  7. Click the Copy Token button
    Screen Shot 05-08-19 at 10.35 AM.PNG
    Note:  Its very important you copy and save this token somewhere. Once you close this window you will not be able to retrieve this value again. You will have to delete the token and create a new one.

 

Step 2: Configure Workspace ONE with Okta API Information

  1. Log into the Workspace ONE Admin Console
  2. Click on Identity & Access Management -> Setup -> Okta
    Screen Shot 05-08-19 at 10.41 AM.PNG
    Note: If you are using Chrome, please be aware of Chrome auto filling any fields.

  3. Enter your Okta Cloud URL.
    Note: Do NOT use the Admin URL!!
    Screen Shot 05-08-19 at 12.19 PM.PNG

  4. Paste your Okta API Token
  5. Select the username search parameter that will match in Okta.
  6. Click Save

 

NOTE: Okta Applications will NOT appear in the Workspace ONE Admin Console

 

Step 3: Testing

  1. Log into Workspace ONE with a directory account.
  2. You should now see all your Okta Applications along with any other applications configured in Workspace ONE.

Screen Shot 05-08-19 at 12.38 PM.PNG

                                                                    down_arrow_clip_art_7569.jpg

Screen Shot 05-08-19 at 12.38 PM 001.PNG

The release of Workspace ONE 19.03 brought in a very seamless integration of Okta Applications.

 

If you have integrated the two solutions previously you will recall the number of steps required to create and entitle new applications in Workspace from Okta. This integrations you to create and entitle applications in Okta and have them seamless appear in Workspace ONE along with your Native and Virtual Applications.

 

Lets walk through the steps to integrate the two solutions.

 

In this blog we are going to assume that you have existing connectors for Workspace ONE UEM and Workspace ONE Identity. We are also assuming you have your Workspace ONE Identity access policies already configured for Mobile SSO, Certificate or Password (Cloud Deployment).

 

 

Part 1: Core Setup and Configuration

The objective of this section to configure Okta to delegate authentication to Workspace ONE Identity where Mobile SSO and Device Compliance are configured.

 

Step 1:  Exporting the Workspace ONE IdP Metadata

  1. Log into Workspace ONE Identity Console -> Catalog -> Settings
  2. Click on "Identity Provider (IdP) metadata" and save the file locally.
    Screen Shot 04-26-19 at 03.16 PM.PNG
  3. Scroll down to the Signing Certificate Section and Download.
    Screen Shot 04-26-19 at 03.30 PM.PNG

Step 2: Add Identity Provider to Okta

  1. Log into your Okta Admin Console
  2. Click on Security -> Identity Providers -> SAML 2.0 Identity Provider
  3. Click on Add Identity Provider
  4. Provider a name: ie. Workspace ONE
  5. For IdP Username, select "idpuser.subjectNameId"
  6. For "If no match is found", select "Redirect to Okta sign-in page"
  7. For your "IdP Issuer URI", retrieve and paste this value from your SAML Metadata you downloaded in step one.
  8. For your "IdP Single Sign-On URL",retrieve and paste this value from your SAML Metadata you downloaded in step one.
  9. For the "IdP Signature Certificate, upload the signing certificate you downloaded in Step 1.
  10. Expand the newly created Identity Provider and download the metadata
    Screen Shot 04-26-19 at 03.34 PM.PNG

Step 3: Create Okta Application Source in Workspace ONE Identity

  1. In Workspace ONE Identity Console, click on Catalog -> Settings
  2. Click on Application Sources
  3. Click on Okta
    Screen Shot 04-26-19 at 03.37 PM.PNG
  4. On the Okta Application Source page, click next
    Screen Shot 04-26-19 at 03.38 PM.PNG
  5. Select "URL/XML" and paste the contents of the Okta metdata we downloaded in the previous step.
    Screen Shot 04-26-19 at 03.40 PM.PNG
    If you chose manual, the mappings should be follow as below:
    Screen Shot 05-09-19 at 12.36 PM.PNG

  6. On the Access Policies page, click next (see note below):
    Screen Shot 04-26-19 at 03.41 PM.PNG

    Note: For the purpose of this blog we are using the "default_access_policy_set". However, it is recommended that you create an access policy specific for the Okta Application Source.  The reason for this recommendation is that you'll likely not want any fallback mechanisms when performing Mobile SSO (so we can present a error message to enroll your device). However, when you enroll your device into Workspace ONE UEM you probably want a fallback mechanism.

  7. Click Save on the summary page.

 

Step 4: Create Okta Routing Rules

  1. Log into the Okta console.
  2. Go to Security -> Identity Providers
  3. Click on Routing Rules
    Screen Shot 05-02-19 at 11.18 AM.PNG
  4. Click Add Routing Rule
  5. Provide a Rule Name
  6. Select the platforms that you want to using Workspace ONE Identity (ie. IOS/Android)
  7. Select the applications that you want to use Workspace ONE Identity
  8. Select the Identity Provider we created previously
    Screen Shot 05-02-19 at 11.21 AM.PNG
  9. Click Create Rule

 

Step 5: Testing

  1. Access your Salesforce development tenant
  2. Select to Authenticate with Okta
  3. Based on your Okta Rules, you should be redirected to Workspace ONE Identity.
  4. Authenticate within WS1
  5. You should return back to Okta and be redirected and successfully authenticated into SalesForce

Troubleshooting Tips

 

  1. Ensure your user is entitled to Salesforce within Okta.
  2. Verify the IdP Issuer in Okta is correct:

    https://aw-sdsatest.vidmpreview.com/SAAS/API/1.0/GET/metadata/idp.xml
  3. Verify the username values we are sending from Workspace ONE to Okta will match:
    Screen Shot 05-03-19 at 10.07 AM.PNG  TO Screen Shot 05-03-19 at 10.09 AM.PNG

 

The AirWatch Provisioning App within Workspace ONE is still relatively new and although it has it quirks, it can still be useful in certain use cases.

 

So what is the AirWatch Provisioning App used for?

 

The app is designed for the use cases where there is no on premise ldap server that can be used with the Workspace ONE UEM Cloud Connector to synchronize users.  This app can be used when users are created in Workspace ONE Identity via SCIM or JIT. Workspace ONE Identity will then create the users in Workspace ONE UEM.

 

Lets first discuss some important information about using the AirWatch Provisioning App in Workspace ONE:

 

  • Currently, Workspace ONE will only provision at the top level (Customer) Organization Group (OG) in Workspace UEM.
  • An LDAP Server can NOT be configured at the top level OG in Workspace ONE UEM (unless the users exist in the directory that will be created - but if this is the case, you shouldn't be using the provisioning adapter)
  • Workspace ONE Identity needs to be configured as a SAML Provider at the top level OG.
  • If you are using JIT to create users in Workspace ONE Identity, you MUST send a valid GUID to Workspace ONE has part of the SAML attributes. This is required if you plan on using the Workspace ONE Hub native application to enroll your device. This GUID will be mapped to the External ID and provisioned to Workspace ONE UEM. See  https://www.uuidgenerator.net/ as an example.
  • If you are using JIT to create users in Workspace ONE Identity, you need to use a web browser to log into Workspace ONE initially before using the Workspace ONE Hub native app. This limitation is because the user needs to exist in UEM at the time of enrollment.

 

Step 1: Export your Workspace ONE IDP Metadata

  1. Log into Workspace ONE Identity and go to Catalog -> Settings
  2. Click on SAML Metadata
  3. Download your "Identity Provider (IdP) metadata"
    Screen Shot 04-25-19 at 01.13 PM.PNG

 

Step 2: Configure UEM to use SAML Authentication

  1. Log into Workspace ONE UEM
  2. Go to Group & Settings -> All Settings -> System -> Enterprise Integration -> Directory Services
  3. Ensure Directory Type is set to "None"
  4. Enable "Use SAML for Authentication"
  5. Under Enable SAML Authentication for*, check Self-Service Portal and Enrollment.
  6. Enable "Use New SAML Authentication Endpoint"
    Screen Shot 04-25-19 at 01.19 PM.PNG
    Note: This step might be a bit confusing as to why we have to configure UEM in this manner. It was confusing to me at first.  The provisioning adapter in Workspace ONE Identity will leverage the REST API to create accounts in UEM. To create user accounts in UEM (of Directory Type), it requires that either a Directory is configured or SAML is enabled. As mentioned earlier, we can not enable a directory so we essentially have to configure SAML. 


  7. In the SAML 2.0 section, click upload to Import Identity Provider Settings
  8. Select the metadata you downloaded in Step 1.
  9. Scroll down and click save.

 

Step 3: Add AirWatch Provision App in Workspace ONE Identity

  1. In Workspace ONE Identity, go to Catalog-> New
  2. Browse from the Catalog and select "AirWatch Provisioning"
    Screen Shot 04-23-19 at 02.47 PM 002.PNG
  3. Click Next
  4. Edit the Single Sign-On URL and Recipient URL with your UEM server
    Screen Shot 04-25-19 at 02.13 PM.PNG
  5. Keep the "default_access_policy_set" and Click Next
  6. Click Save
    Screen Shot 04-23-19 at 02.49 PM 001.PNG
  7. Select the AirWatch Provisioning App and Click Edit
  8. Click Next
  9. On the Configuration Tab, enable "Setup Provisioning"
    Screen Shot 04-25-19 at 02.13 PM 001.PNG
  10. Click Next
  11. Enter your AirWatch Device Services URL
  12. Enter your Admin Username
  13. Enter your Admin Password
    Note: Whenever you edit this application be very careful of Chrome's password auto-fill. It will update the password if you have one saved in chrome. After you hit test connection it will revert back to your saved password in Chrome.
  14. Enter your AirWatch API Key
    Note: If you don't have an API Key, in UEM, go to Groups & Settings -> All Settings -> System -> Advanced -> API -> REST API
    Click Override -> Add
    Provide a Service Name with the account type of Admin.  Copy the API Key.
  15. Enter your top level OG Group ID
  16. Click Test Connection and validate connectivity.
  17. Click Enable Provisioning
    Screen Shot 04-25-19 at 01.39 PM.PNG
  18. Verify the mapping are correct. If you are using JIT, make sure all these attributes have come over in the SAML assertion.
    Screen Shot 04-23-19 at 02.53 PM 001.PNG
  19. Under Group Provisioning, add any groups you want to provision to UEM.
    Screen Shot 04-23-19 at 02.53 PM 004.PNG
  20. Click Next
  21. Click Save

 

Note: If you get an error when saving, please see the note earlier about chrome's auto password fill.

 

Step 4: Entitle Users to the AirWatch Provisioning App

You have the option of entitling users individually or using a group. If you are using JIT you might want to consider using a dynamic group.

 

  1. Click the Assign button on the AirWatch Provisioning App
  2. Search for the user and/or group
  3. Under "Deployment Type" you MUST Select Automatic. If you leave the default "User Activated" it will never get provisioned to the user.

Screen Shot 04-23-19 at 02.55 PM 001.PNG

 

Step 5: Create a Dynamic Group (Optional)

If you are using JIT to create users into Workspace ONE, it easier to create a dynamic group and assign that group to the provisioning adapter.

  1. Click on "Users & Groups"
  2. Click on Groups
  3. Click Add Group
  4. Provide a group name and Click Next
  5. Do not select any users and Click Next
  6. Under Group Rules, you can either choose based on the JIT Directory that was created or the domain you chose for the JIT Users
  7. Click Next
  8. Click Next to exclude users
  9. Click Create Group

 

Troubleshooting

  1. If you receive the error "Error not provisioned" in the assignment screen and you hover over the error message and see "Failed to validate attributes while trying to provision user" this means that the values for the attributes you used in Attribute Mappings of the provisioning adapter configuration are either null or missing. Please make sure you create the user in Workspace ONE Identity with all the necessary attributes to create the account in Workspace ONE UEM. This includes the External ID. Please see the note at the beginning of the blog regarding the External ID
    Screen Shot 05-01-19 at 09.16 AM.PNG
  2. While trying to enroll your device with the HUB application application you receive a generic error like "An Error has occurred". See the note about External ID.
  3. When trying to provision the Mobile SSO profile you receive an error that the PrincipalName contains an invalid value.
    Screen Shot 05-01-19 at 09.04 AM.PNG
    This means that you have probably created the Workspace ONE UEM account with an email as the Username. When the Mobile SSO certificate payload was created, it uses the username as the principal name on the certificate. Unfortunately you can not have the "@" character in the principle name. You have two choices to resolve this issue:
    a) In the AIrWatch Provisioning Adapter mappings, use another attribute to represent the username that does not contain the @ sign. You might need to adjust the values being imported into Workspace ONE identity (whether by JIT or via the connector). Please make sure the username and the prefix of the UPN remain the same.
    b) Use a lookup in Workspace ONE UEM to parse the prefix of the email address and use that in the certificate payload:
    Group & Settings -> All Settings -> Devices & Users -> General -> Lookup Fields
    Add Custom Field
    Create a Name such as EmailNickName and use a regex such as ".+?(?=@)"
    Screen Shot 05-01-19 at 09.14 AM.PNG
    You can then use "EmailNickName" in your Certificate Payload
    Screen Shot 05-01-19 at 09.12 AM.PNG









In this blog post, we will walk through the steps to configure IOS Mobile SSO.

 

I will be assuming that your Workspace ONE UEM and Workspace ONE Identity Manager environments have not been previously integrated.

 

This blog will assume that you already have an Enterprise Cloud Connector installed and syncing with Workspace ONE UEM.

 

In this blog, we'll cover:

  1. Configure Workspace ONE Identity in the UEM Console
  2. Enable Active Directory Basic
  3. Enable Mobile SSO
  4. Basic Troubleshooting

 

Validation of Pre-requisites

 

  1. Log into Workspace ONE UEM -> Global Settings -> All Settings -> System -> Enterprise Integration -> Cloud Connector
  2. Ensure AirWatch Cloud Connector is enabled
  3. Perform a Test Connection. Make sure the connection is active
    Screen Shot 04-22-19 at 01.33 PM.PNG
  4. Click on Directory Services from the left menu
  5. Ensure your directory has been configured and you can perform a successful test connection
    Screen Shot 04-22-19 at 01.39 PM.PNG
  6. Close from Settings and go to accounts on the main left in Workspace ONE UEM.
  7. Make sure you have users being synchronized into Workspace ONE UEM
    Screen Shot 04-22-19 at 01.42 PM.PNG

 

Step 1: Configure Workspace ONE Identity in the UEM Console

Although this step is not absolutely required to get Mobile SSO working, I highly recommend you configure this as its required for Device Compliance, Unified Catalog and UEM Password Authentication.

In previous versions of Workspace ONE UEM, there was a lot of manual configuration required to enable Workspace ONE Identity.  Using the wizard in Workspace ONE UEM we can automate a lot of these tasks.

 

Click on Getting Started

  1. Under Workspace ONE -> Begin Setup
    Screen Shot 04-22-19 at 01.56 PM.PNG
  2. Under Identity and Access Management -> Click Configure for "Connect to VMware Identity Manager"
    Screen Shot 04-22-19 at 01.58 PM.PNG
  3. Click Continue
    Screen Shot 04-22-19 at 02.01 PM.PNG
  4. Enter your Tenant URL, User name, and Password
    Screen Shot 04-22-19 at 02.03 PM 001.PNG
  5. Click Save
  6. If you check your Workspace ONE Identity tenant, you will see that AirWatch configuration as been completed: Identity & Access Management -> Setup -> AirWatch

 

Step 2: Enable Active Directory Basic

VMware recommends you download and install the VMware Identity Manager connector to synchronize users from your Active Directory to Workspace ONE Identity. However, for the purpose of this blog we are going to leverage to built-in capabilities of Workspace UEM to provision users directly into Workspace ONE Identity.

 

  1. In Workspace ONE UEM, Groups & Settings -> All Settings -> System -> Enterprise Integration -> VMware Identity Manager -> Configuration
  2. You will see under the server settings that "Active Directory Basic" is disabled
    Screen Shot 04-22-19 at 02.18 PM.PNG
  3. Click "Enabled" beside Active Directory Basic
  4. You will be prompted to enter your password
    Screen Shot 04-22-19 at 02.19 PM.PNG
  5. Click Next
  6. Enter a name for your directory (This will be name of the directory in Workspace ONE Identity). You can leave Enable Custom Mapping to standard
    Screen Shot 04-22-19 at 02.21 PM.PNG
  7. Click Save
  8. If everything worked successfully, you should see your a new directory appear in Workspace ONE Identity with your synchronized users:
    Screen Shot 04-22-19 at 02.22 PM.PNG

 

Step 3: Enable Mobile SSO

  1. Lets go back to the "Getting Started Section" of Workspace ONE UEM
  2. Under Workspace ONE -> Continue
  3. Under Identity & Access Management -> Mobile Single-Sign-On, click Configure
    Screen Shot 04-22-19 at 02.33 PM.PNG
  4. Click "Get Started"
    Screen Shot 04-22-19 at 02.35 PM.PNG
  5. Click Configure to use the AirWatch Certificate Authority
    Screen Shot 04-22-19 at 02.38 PM.PNG
  6. Click Start Configuration
    Screen Shot 04-22-19 at 02.40 PM.PNG
  7. Click Finish when complete
    Screen Shot 04-22-19 at 02.41 PM.PNG
  8. Click Close

Basic Troubleshooting

There are a variety of reasons that Mobile SSO can fail. Lets go over a few of the common reasons.

 

  1. You are prompted for a username/password or the Workspace ONE Domain chooser when doing Mobile SSO
    The problem here is that Mobile SSO has failed and Workspace ONE Identity is triggering the fallback authentication mechanism. For the purpose of troubleshooting, I recommend removing the fallback mechanism. In the IOS  Policy, remove Certificate Authentication and Password (Local Directory). When you test again you will be prompted with an error message instead.
    Screen Shot 04-22-19 at 03.22 PM.PNG
  2. You are prompted with an error  message "Access denied as no valid authentication methods were found"
    a) Check to make sure the "Ios_Sso" profile was pushed to the device. By default, when the profile is created it does not have an assignment group. If not, create an smart group and assign the profile and publish.
  3. You received the error "The required field “Keysize” is missing" when deploying the IOS Mobile SSO Profiless
    Something went wrong with the import of the KDC Certificate from Workspace ONE Identity to UEM.
    a)Log into Workspace ONE Identity -> Identity & Access Management -> Identity Providers -> Built-In and download the KDC Certificate:
    Screen Shot 04-22-19 at 04.20 PM.PNG
    b) Now switch back to UEM, Devices -> Profiles & Resources -> Profiles
    c) Edit the IOS Profile
    d) Click Credentials and re-upload the KDC Certificate.

  4. You received the message "Kerberos NEGOTIATE failed or was cancelled by the user"

    Unfortunately this is a catch all error message for mobile sso failures can could be many things. I'll try to cover some of the common reason here:

    a) In Workspace ONE UEM, check your IOS Mobile SSO profile -> Single Sign-on. Verify the Realm is correct. For production it should be "VMWAREIDENTITY.COM". However if you have localized cloud tenant this can be different (VMWAREIDENTITY.EU, VMWAREIDENTITY.ASIA,  VMWAREIDENTITY.CO.UK, VMWAREIDENTITY,COM.AU, VMWAREIDENTITY.CA, VMWAREIDENITY.DE).  For non-production, you might be on the vidmpreview.com domain. If this is the case, it should be "VIDMPREVIEW.COM"

    b) When you use the wizard to create the Mobile SSO configuration, it will automatically add the application bundle id's where Mobile SSO is allowed. You will need to either enter all your application bundle id's into the profile or optionally delete them all. If you don't specify the bundle id's, it will allow them all.  I recommend for a POC, you leave this blank.

    c) Mobile SSO on IOS is based on Kerberos. The kerberos negotiation works of Port 88 on UDP. Ensure that your firewall is not blocking this port.

    d)The built-in AirWatch Certificate Authority uses the username (usually sAMAccountName) as the principal name on the certificate provisioned to the device. The kerberos negotiation will use the username to formulate a user principle name which needs to match in Workspace ONE Identity. A problem can occur when organizations define their UPN with a different prefix than the sAMAcountName. So if my my username is "jdoe" but my UPN is "john.doe@domain.com". In this scenario, Mobile SSO will fail. In this scenario, we can:


    i) Sync sAMAccountName as the UPN in Workspace ONE Identity (Note: This can have potential issues with downstream applications but you can always pull the UPN as a custom attribute as well)
    ii) Use a custom certificate authority in Workspace ONE UEM and configure a kerberos template with the correct values.

We come across the scenario quite often when customers want to leverage Microsoft Authenticator when using Workspace ONE UEM and/or Horizon.

 

In this blog, I'd like to go through the various options and outline the user experience with each of the options.

 

The  main uses case we see are:

 

  • Microsoft MFA for Horizon Desktop
  • Microsoft MFA for SaaS Applications federated directly with Workspace ONE.
  • Microsoft MFA for Device Enrollment in Workspace ONE UEM
  • Microsoft MFA for SaaS Applications federated with Azure AD. (Including Office 365)

 

There are 3 integration options that you can consider to integrate Microsoft Authenticator with Workspace ONE. The use cases previously mentioned can fit into one ore more of the following integration options.

 

1. Azure AD as a 3rd Party IdP in Workspace ONE

 

Use Cases:

  • Microsoft MFA for Horizon Desktop
  • Microsoft MFA for SaaS Applications federated directly with Workspace ONE.
  • Microsoft MFA for Device Enrollment in Workspace ONE UEM

 

Use Cases not Supported:

  • Microsoft MFA for SaaS Applications federated with Azure AD. (Including Office 365)

 

 

In this option, the following needs to be configured:

  • Azure AD configured as a 3rd Party IdP in Workspace ONE
  • Workspace ONE configured as an enterprise app in Azure
  • Conditional Access Policy Configured in Azure AD to require Microsoft Authenticator for the Workspace ONE Application.

 

Screen Shot 04-17-19 at 03.11 PM.PNG

Lets walk through the authentication flow in this option:

  1. The user will access their Horizon Desktop (or any application that is federated directly with Workspace ONE).

  2. The application will send a SAML Authentication Request to Workspace ONE
  3. Assuming the access policy in Workspace ONE is configured for Azure Authentication, the user will be redirected to Azure AD.
  4. The user will enter their email address.
  5. Assuming the domain is not currently federated with another IdP, Azure will prompt the user to enter their password.
  6. Azure conditional access policies will then trigger for Microsoft MFA.
  7. The user will be returned to Workspace ONE and subsequently authenticated to Horizon. (Note: Horizon should be configured with TrueSSO for optimal user experience).

 

2. Workspace ONE as a Federated Domain in Azure AD

 

Use Cases:

  • Microsoft MFA for SaaS Applications federated with Azure AD. (Including Office 365)

 

 

Use Cases not supported:

  • Microsoft MFA for Horizon Desktop
  • Microsoft MFA for SaaS Applications federated directly with Workspace ONE.
  • Microsoft MFA for Device Enrollment in Workspace ONE UEM

 

 

 

In this option, the following needs to be configured:

  • Azure domain must be federated to Workspace ONE
  • Conditional Access Policy Configured in Azure AD to require Microsoft Authenticator for the Workspace ONE Application.
  • Mobile SSO/Certificate Authentication Configured in Workspace ONE

Screen Shot 04-17-19 at 05.29 PM.PNG

Lets walk through the authentication flow in this option:

  1. The user will access Office 365 (or any application federated with Azure AD).
  2. The user will enter their email address.
  3. The user will be redirected to Workspace ONE
  4. Workspace ONE will authenticate the user using Mobile SSO, Certificate or some other authentication mechanism (as well as checking device compliance).
  5. Workspace ONE will respond with a successful response back to Azure AD.
  6. Azure conditional access policies will then trigger for Microsoft MFA.
  7. The user will be successfully authenticated into Office 365 (other other Azure federated application).

 

3. Workspace ONE with Microsoft Azure MFA Server

 

Use Cases:

  • Microsoft MFA for Horizon Desktop
  • Microsoft MFA for SaaS Applications federated directly with Workspace ONE.
  • Microsoft MFA for Device Enrollment in Workspace ONE UEM
  • Microsoft MFA for SaaS Applications federated with Azure AD. (Including Office 365)*

          *For Office 365 (and other apps federated with Azure), the Azure domain must be federated with Workspace ONE.

 

Use Cases not supported:

  • N/A

 

In this option, the following needs to be configured:

  • Azure MFA Server downloaded and installed on premises.
  • Workspace ONE Connector installed on premise.
  • Workspace ONE configured as a radius client in Azure MFA Server

 

 

Screen Shot 04-17-19 at 05.41 PM.PNG

Lets walk through the authentication flow in this option:

  1. The user will access any application federated with Workspace (or Horizon/Citrix application).
  2. Workspace ONE will prompt for their username/password
  3. After clicking "Sign-In", a radius call via the connector will be made to the Microsoft Azure MFA Server
  4. The MFA server will push a notification to the device to approve the request:

If you have configured Okta as a 3rd Party IDP in Workspace ONE you might have noticed that the "Logout" function in Workspace ONE doesn't log you out of your Okta session. The reason for this is that Okta does not include the "SingleLogoutService" by default in the metadata that is used when creating the 3rd Party IDP in Workspace ONE.

 

There are a couple extra steps that you need to do to enable this functionality. Before you begin, please make sure you download your signing certificate from Workspace ONE.

 

  1. Log into Workspace ONE
  2. Click on Catalog -> Settings (Note: Don't click the down arrow and settings)
    Screen Shot 04-17-19 at 10.55 AM.PNG
  3. Click on SAML Metadata
  4. Scroll down to the Signing Certificate and Click Download
    Screen Shot 04-17-19 at 11.01 AM.PNG

Now you will need to log into your Okta Administration Console.

  1. .Under Applications -> Click on the Workspace ONE application that you previously created
    Screen Shot 04-17-19 at 11.04 AM.PNG
  2. Click on the General Tab
  3. Under SAML Settings -> Click Edit
  4. Click Next
  5. Click on "Show Advanced Settings"
    Screen Shot 04-17-19 at 11.06 AM.PNG
  6. Enable the Checkbox that says "Enable Single Logout"
    Screen Shot 04-17-19 at 11.07 AM.PNG
  7. Under "Single Logout URL", enter:  "https://[WS1Tenant]/SAAS/auth/saml/slo/response"
    Screen Shot 04-17-19 at 11.09 AM.PNG
  8. Under SP Issuer, copy the value you have configured for Audience URI (SP Entity ID). This value should be: "https://[WS1Tenant]/SAAS/API/1.0/GET/metadata/sp.xml"
    Screen Shot 04-17-19 at 11.12 AM.PNG
  9. Under "Signature Certificate", browse to the location you downloaded the Workspace ONE certificate in the previous steps.
  10. Click Upload Certificate
  11. Click Next
  12. Click Finish
  13. Click on the "Sign On" tab
  14. Click on Identity Provider Metadata
    Screen Shot 04-17-19 at 11.15 AM.PNG
  15. You will notice that your Identity Provider Metadata now includes the SingleLogoutService:
    Screen Shot 04-17-19 at 11.19 AM.PNG
  16. Copy this metadata.

 

Now switch back to Workspace ONE

 

  1. Go to Identity & Access Management
  2. Click on Identity Providers
  3. Click on your Okta 3rd Party IDP you previously created
  4. Paste your new Okta Metadata and click "Process IdP Metadata"
    Screen Shot 04-17-19 at 11.22 AM.PNG
  5. Scroll down to "Single Sign-out Configuration" and check "Enable". (Note: Make sure the other two values are left blank)
    Screen Shot 04-17-19 at 11.24 AM.PNG

Now you should be able to logout from Workspace ONE and be signed out of both solutions.

 

Screen Shot 04-17-19 at 11.25 AM.PNG

VMware's Workspace ONE provides a digital workspace platform with a seamless user experience across any application on any device. Users can access a platform native catalog to download and install applications regardless of whether its an IOS, Android, Win10 or MacOS device. They can access both Web and SaaS applications as well as their Virtualized applications including Horizon and Citrix.  Workspace ONE is designed to keep the user experience "Consumer Simple" while keeping the platform "Enterprise Secure".

 

VMware promotes the "Zero-Trust" approach when accessing corporate applications. Workspace ONE Unified Endpoint Management is a critical element to achieve a zero-trust model to ensure the device itself is secure enough to access your corporate data.  However, to achieve a zero-trust model we need to include both the Device Trust and the Identity Context.  This is where the Risk-Based Identity Assurance offered by RSA SecurID Access becomes the perfect complement to Workspace ONE.

 

RSA SecurID Access makes access decisions based on sophisticated machine learning algorithms that take into consideration both risk and behavioral analytics. RSA SecurID Access offers a broad range of authentication methods including modern mobile multi-factor authenticators (e.g., push notification, one-time password, SMS and biometrics) as well as traditional hard and soft tokens.

 

I'm pretty excited about the integration between Workspace ONE and RSA SecurID Access because its offers extreme flexibility to control when and how multi-factor authentication will be used. After the initial setup, it also allows me to control everything from Workspace ONE.

 

RSA SecurID Access provides 3 levels of assurance that you can leverage within your access policies. You have full control to modify the authenticators into the appropriate levels based on your licensing from RSA.

 

Screen Shot 04-15-19 at 02.09 PM.PNG

 

You can create Access Policies in RSA SecurID Access that will map to the appropriate assurance levels:

 

Screen Shot 04-15-19 at 02.14 PM.PNG

 

In my environment, I've created 3 policies:

Screen Shot 04-15-19 at 03.09 PM.PNG

Once you've completed your access polices you can then add your Workspace ONE tenant as an relying party.

 

Screen Shot 04-15-19 at 05.11 PM.PNG

 

Now this is where things get really interesting and you'll see why i'm excited about this integration. Its fairly common for a digital workspace or web portal to call out to an MFA provider to perform the necessary authentication and return the response. The problem that typically comes into play is whether the authenticators being used for MFA are too much or too little for the application being accessed.  In most cases, the MFA provider is not aware of what application is being accessed and is only responding the call from the relying party.  Keep in mind that "User Experience" is at the forefront of the Workspace ONE solution.

 

The integration between Workspace ONE and RSA SecurID Access allows us to control which Access Policy (or level of assurance) will be used from within Workspace ONE.

 

In Workspace ONE, we can create the same policies that we did in RSA SecurID Access:

Screen Shot 04-15-19 at 02.46 PM.PNG

 

In Workspace ONE we can directly assign Web, SaaS or Virtual applications that require High Assurance into the "High Assurance" access policy and apps that require "Medium or Low Assurance" into the appropriate policy. When applications are accessed in Workspace ONE, it will automatically send the request to RSA SecurID Access with the requested policy to use for authentication.

 

So how does Workspace ONE specify which policy RSA SecurID should use for authentication? Its actually quite simple.  The integration between Workspace ONE and RSA SecurID Access is based on SAML.

 

Initial authentication into Workspace ONE will typically come from Mobile SSO or Certificate Based Authentication (although other forms of authentication are available). After the initial authentication or once the user clicks on a specific application, Workspace ONE will send a SAML Authentication Request which will include the subject who needs additional verification:

 

<saml:Subject xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">

        <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">steve</saml:NameID>

</saml:Subject><samlp:NameIDPolicy AllowCreate="false"

 

When the SAML Request is sent from Workspace ONE, it will also include the access policy as part of the SAML AuthnContextClassRef:

 

<saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:rsa:names:tc:SAML:2.0:ac:classes:spec::LowWS1</saml:AuthnContextClassRef>

</samlp:RequestedAuthnContext>

 

You can see in the AuthnContextClassRef we are specifying the specific policy that RSA SecurID Access should use for authentication. 

 

When you create a 3rd Party IDP for RSA SecurID Access, you can specify the AuthnContextClassRef when defining the authentication methods:

Screen Shot 04-15-19 at 05.02 PM 001.PNG

Screen Shot 04-15-19 at 05.03 PM.PNG

 

I've actually left out a key element of the RSA SecurID Access solution, which is the Risk Level. Even though we've specifically called out the Low Assurance Policy, we can have RSA dynamically change that to High based on the user's risk score. RSA SecurID Access can use an "Identity Confidence" score to choose the appropriate assurance level. This is configured in the access policy:

 

Screen Shot 04-17-19 at 01.45 PM.PNG

 

By leveraging RSA SecurID Access with VMware Workspace ONE we can now have risk-based identity assurance on a per app level within Workspace ONE. For current Workspace ONE customers, this integration is based on SAML so it does not require radius and has no dependency on the VIDM Connector.

 

Together this keeps the user experience great on apps that might not need a high level of assurance and keeps the enterprise secure on the apps that require the high level of assurance.

If you have followed the documentation for ADFS Integration with WS1, you configured the WS1 to send “${user.domain}\${user.userName}” as the NameID. However, you will probably need to send additional attributes in case other applications are looking for things like UPN. The following is how you would configure this:

 

  1. Under Attribute Mapping, enter the Name of the Attribute using Microsoft Schema syntax. The following is a list of common attributes:
    1. http://schemas.xmlsoap.org/ws/2005/05/identity/claims/email
    2. http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname
    3. http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
    4. http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn
  2. Enter the Attribute Name and the matching value:

 

ADFS Configuration

  1. Under Claims Provider Trusts, edit the claims for the Workspace ONE Claims Provider Trust
  2. Add a Rule
  3. Select the attribute and pass all values.
  4. Save
  5. In the Relying Party Trust
  6. Edit the claims
  7. Create a New Transform Rule to Set the NAME to the UPN