Skip navigation

Steve's IDM Blog

13 posts

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.

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

 

NOTE: There is currently a known issue that will prevent you from enrolling a device with the Workspace ONE Intelligent Hub application using the Okta Unique Identifier. This should be fixed in the September time frame. However, if your UEM environment is CN135 the fix is already deployed.

 

If you follow these instructions, keep in mind that device enrollment will NOT work until this fix is in place.

 

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:

  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
    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 and Click Send

 

{  
"type":"OTHER_DIRECTORY",  
"domains":["Okta"],  
"name":"Okta"  
}  

 

You should see a similar result

 

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
  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 2019-08-13 at 3.58.43 PM.png
  10. Click on the Provisiong Tab and Click Configure API Integration
  11. Click Enable API Integration
  12. Enter the SCIM 1.1 Base URL in the following format: https://[tenant url]/SAAS/jersey/manager/api/scim
  13. Paste your bear token that was created in the earlier step with postman.
  14. Click Test API Credentials
  15. Ensure you have a "Success" before proceeding.
  16. Click Save
  17. Scroll down to the Attribute Mapping Section
  18. Delete the following attributes
    -entitlements
    -roles
  19. Click "Go to Profile Editor"
  20. 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. Select Attribute Required
    4. Save
  21. 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. Select Attribute Required
    4. Save
  22. 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. Select Attribute Required
    4. Save
  23. Click on Mappings
  24. Click on the Okta to Workspace ONE SCIM Tab
  25. 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
  26. Remove the mappings for displayName and locale
  27. Click Save Mappings
  28. Click Apply Updates Now
  29. Click on the Provisioning Tab again
  30. Click Edit and Enable Provisioning for Create Users and Deactivate Users. Note: Do not select update users
  31. Click Save
  32. Using a test user, assign the user the Workspace ONE SCIM application
  33. If you receive an error such as below you might need to un-map additional attributes.

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",
        "userStatus": "1",
        "domain": "1dsavm.com",
        "userStoreUuid": "987dca12-22e3-4ec6-8958-110cca481c3d",
        "externalUserDisabled": false,
        "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

This guide provides step by step instructions to configure and test Workspace ONE as a trusted federation identity provider with OpenAM.

Prerequisites.

  • Test Instance of ForgeRock OpenAM v 5.5  (or higher) installed and configured.
  • Workspace ONE tenant
  • Configured Service Providers (ie. Salesforce, O365 etc..)
  • This solution will only work if you have architected OpenAM to leverage an IDP Proxy as below:

 

 

Note: I've been told by ForgeRock that this will also work using their Identity Gateway however I've not personally tested this.

 

Download Workspace ONE IDP Metadata

  1. Log into Workspace ONE Administration console and go to:
    1. Catalog -> Settings -> SAML Metadata -> Identity Provider (IDP) metadata
  2. Download and Save the file.
  3. Log into the OpenAM Console
  4. Click on the Realm where you want to configure Workspace ONE. This doc will assume you are configuring the Top Level Realm (/).
  5. Click Configure SAMLv2 Provider from the Dashboard

Create Workspace ONE as an Identity Provider in OpenAM

  1. Log into the OpenAM Console
  2. Click on the Realm where you want to configure Workspace ONE. This doc will assume you are configuring the Top Level Realm (/).
  3. Click Configure SAMLv2 Provider from the Dashboard
  4. Click “Configure Remote Identity Provider”
  5. Select “File” and Upload the Workspace ONE metadata:
  6. Select an existing Circle of Trust. Note: WorkspaceONE needs to be in the same COT as other SP’s and IDP’s that will be used in this environment.
  7. Select OK
  8. Click Save
  9. Click Create Authentication Scheme and Module

 

Configure IDP Proxy

  1. From the left menu, click on Applications -> SAML
  2. Ensure your IDP Proxy is listed and is of type “SP;IDP”
  3. Click on your IDP Proxy from the Entity Providers List
  4. Click on the IDP Tab
  5. Click on Advanced
  6. Scroll down to “IDP Finder Implementation”
  7. Add the following if not there:
    1. IDP Finder Implementation Class: com.sun.identity.saml2.plugins.SAML2IDPProxyFRImpl
    2. IdP Finder JSP: proxyidpfinder.jsp
  8. Enable the Proxy IDP Finder for all SP’s.
  9. Click Save and then it the back button.

 

Configure Service Providers

  1. In the Federation Tab, copy the Entity ID for Workspace ONE and the Entity ID for the OpenAM IDP instance that will handle authentications that are not sent to Workspace ONE
  2. Click on the entity id for your service provider
  3. Click on the Advanced Tab
  4. Scroll down to IDP Proxy and Enable the Proxy
  5. Check “Proxy all Requests”
  6. Check “Use IDP Finder”
  7. Set the proxy count to something greater than 2.
  8. In the Proxy List, paste the Entity ID’s of all your IDP servers
  9. Click Save and Back.

 

Export IDP Proxy Metadata

  1. In your browser, go to: http://[openAM-Host]:8080/openam/saml2/jsp/exportmetadata.jsp??entityid=[EntityOfIDPProxy]

      Ie. http://openam.one-identity.ca:8080/openam/saml2/jsp/exportmetadata.jsp?entityid=http://openam.one-identity.ca:8080/openam

 

Configure OpenAM as a SP in Workspace ONE

  1. Log into Workspace ONE Administration -> Catalog
  2. Click on Add Application -> Create a new one
  3. Provide a name ie. OpenAM
  4. Leave SAML 2.0 Post as the profile and Click Next
  5. Under Configuration, paste the SAML Metadata and Click Save
  6. Select Sign Assertion
  7. Select the correct NameID value to match the value that OpenAM is expecting.
  8. Click on Entitlements and add the necessary entitlements.
  9. Click Save

 

Update Workspace ONE Policies (optional)

  1. Log into the Workspace ONE Administration -> Identity and Access Management
  2. Configure the appropriate authentication policies as per your requirements Refer to VMware Documentation on how to configure policies.

 

Test the Configuration

We should test our configuration out first to ensure everything is working before we modify the JSP to automate the IDP selection.

  1. Log into your SP and you should be redirected to your IDP Finder on the IDP Proxy:
  2. Test out all you configured IDP’s to ensure that Federation is working all the way through.

 

Update ProxyIDPFinder.JSP to Automate the Selection.

  1. You will need to SSH into your IDP Proxy Host and modify the proxyidpfinder.jsp file which is located in $TOMCAT_HOME/webapps/openam
  2. Open up the file in your file editor and search for the following block of code:
  3. Comment out the first line
  4. You will then need to prepare your code to select the user agent.
    1. Using a Base64 Encoding tool such as https://www.freeformatter.com/base64-encoder.html you will need to encode each of your IDP Entity ID’s.
  5. Once you have each of your encoded IDP’s, you can create something similar to below:

String userAgent = request.getHeader("User-Agent");
if(userAgent != null && userAgent.indexOf("Android") != -1){
samlIdP="aHR0cHM6Ly9kc2FzLnZtd2FyZWlkZW50aXR5LmNvbS9TQUFTL0FQSS8xLjAvR0VUL21ldGFkYXRhL2lkcC54bWw=";
}else if (userAgent != null && userAgent.indexOf("iPhone") != -1){
samlIdP="aHR0cHM6Ly9kc2FzLnZtd2FyZWlkZW50aXR5LmNvbS9TQUFTL0FQSS8xLjAvR0VUL21ldGFkYXRhL2lkcC54bWw=";
}else{
samlIdP="aHR0cDovL29wZW5hbS5vbmUtaWRlbnRpdHkuY2E6ODA4MC9vcGVuYW0=";
}

This guide provides step by step instructions to configure and test Workspace ONE as a trusted federation identity provider with Oracle Access Manager 12c.

 

 

Prerequisites.

  • Test Instance of Oracle Access Manager v 12.2.1.0.0 (or higher) installed and configured.
  • Workspace ONE tenant
  • Configured Service Providers (ie. Salesforce, O365 etc..)

 

Download Workspace ONE IDP Metadata

  1. Log into Workspace ONE Administration console and go to:
    1. Catalog -> Settings -> SAML Metadata -> Identity Provider (IDP) metadata
  2. Download and Save the file.
  3. Log into the OAM Console
  4. Click on the Federation Tab
  5. Click on Service Provider Management

 

Create WorkSpace ONE as an Identity Provider in OAM

  1. Log into the OAM Console
  2. Click on the Federation Tab
  3. Click on Service Provider Management
  4. Click on Create Identity Provider
  5. In the Name field, enter “WorkspaceONE”
  6. Under Service Information, upload your Workspace ONE IDP Metadata.
  7. Choose the correct Attribute Mapping to match the value being sent by Workspace ONE in the NameID attribute.
  8. Click Save
  9. Click Create Authentication Scheme and Module

Configure OAM as a SP in Workspace ONE

  1. Download the Oracle Access Manager SP Metadata

http://[OAM_HOST]:14100/oamfed/sp/metadata

  1. Log into Workspace ONE Administration -> Catalog
  2. Click on Add Application -> Create a new one
  3. Provide a name ie. Oracle Access Manager
  4. Leave SAML 2.0 Post as the profile and Click Next
  5. Under Configuration, paste the SAML Metadata and Click Save
  6. Select Sign Assertion
  7. Select the correct NameID value to match the value that OAM is expecting.
  8. Click on Entitlements and add the necessary entitlements.
  9. Click Save

 

Update Workspace ONE Policies (optional)

  1. Log into the Workspace ONE Administration -> Identity and Access Management
  2. Configure the appropriate authentication policies as per your requirements Refer to VMware Documentation on how to configure policies.

 

Update SP Partners to use WS1 for Authentication using WLST

  1. Set Environment Variable
    • $DOMAIN_HOME/bin/setDomainEnv.sh
  2. Start WLST
    • $ORACLE_HOME/oracle_common/common/bin/wlst.sh
  3. Connect to OAM
    • Connect(‘weblogic’,’WeblogicPassword’,’t3://localhost:7001’)
  4. You should now be logged into WLST and ready to issue WLST Commands:
  5. Type “domainRuntime()”
  6. Type the following:

setSPPartnerAlternateScheme("SFDC", "true", httpHeaderName="User-Agent", httpHeaderExpression=".*((Android)|(iPhone)).*", authnScheme="WorkspaceONEFederationScheme")

 

NOTE: Replace “SFDC” with the correct partner name as per your configuration. If you named your Workspace ONE IDP instance differently from the steps in the document, replace with the correct name in the command above.

Screen Shot 11-07-17 at 11.15 AM.PNG

 

For more information on this WLST command and other available commands, please refer to the following documentation:

https://docs.oracle.com/cd/E52734_01/oam/STIAM/if_wlst.htm#STIAM13030

 

 

  1. Type “exit()”

 

Note: There could be a slight delay when updating the configuration via WLST until the changes are propagated across all OAM nodes.