Skip navigation

For updates on this blog and other blogs: Follow @SteveIDM


In this blog we are going to walk through the process of integrating Zoom with Workspace ONE Access.  There are two very important prerequisites before you can setup the SAML integration with zoom:

  1. You need an approved Vanity URL.
  2. Users need to be created with an SSO Profile (unless you are using JIT)


Zoom Vanity URL

In your Zoom administration console, under Admin -> Account Management -> Account Profile. You can apply for the Vanity URL at the bottom of this screen. Note: It might take some time to get this approved by Zoom.


Screen Shot 08-27-20 at 02.01 PM.PNG


Zoom Users

When you create users in Zoom, they need to be created with the "SSO User" feature. Users can be created via CSV or through their API. If you are using the API to create users, you will need to include the "SSOCreate" action:



  "action": "ssoCreate",
  "user_info": {
    "email": "",
    "type": 1,
    "first_name": "Steve",
    "last_name": "Test"


When users are created, you will see the SSO Icon:

Screen Shot 08-27-20 at 01.56 PM.PNG

Zoom Single Sign-On Setup


In order to configure Zoom for Single Sign-On, you will need to your IDP Metadata from Workspace ONE Access.

  1. Log into the Workspace ONE Administration Console
  2. Go to Catalog -> Web Applications and Click the Settings Button
  3. Click on SAML Metadata ->Identity Provider (IdP) Metadata


In your Zoom Administration Console:

  1. Go to Admin -> Advanced -> Single Sign-On
  2. Enter your Sign-in page URL. This can be found in the "md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"" tag. This URL will end in /SAAS/auth/federation/sso
    Screen Shot 08-27-20 at 02.44 PM.PNG
  3. Paste your Identity Provider Certificate (Signing). Note: Proper certificate formatting is not required.
  4. Leave the default SP Provider (SP) Entity ID
  5. In the "Issuer (IDP Entity ID)" enter the value from the WS1 Metadata. This can be found entityID field which is on the first line of the metadata. This URL will end in idp.xml.
  6. Select HTTP-POST for the binding.
  7. Select "SHA-256" for the Signature Hash Algorithm.
    Screen Shot 08-27-20 at 02.45 PM.PNG
  8. Under Security, select Sign SAML Request and Save SAML response logs on user sign-in.
  9. Under Provision User, select "Prior to Sign-in" unless you are doing JIT.
  10. Download your metadata at


Workspace ONE Access Single Sign-On Setup

  1. Log into the Workspace ONE Administration Console
  2. Go to Catalog -> Web Apps
  3. Click New
  4. Provide a Name (ie. Zoom) and an Icon
    Screen Shot 08-27-20 at 02.25 PM.PNG
  5. Click Next
  6. Open the previously downloaded metadata and copy/paste into the URL/XML section.
    Screen Shot 08-27-20 at 02.27 PM.PNG
  7. Click Next, Next Save.
  8. Edit the Zoom Application we just created.
    Screen Shot 08-27-20 at 02.33 PM.PNG
  9. Click Next
  10. Enter the correct Username Value that will be used to match the corresponding users in Zoom.
    Screen Shot 08-27-20 at 02.31 PM.PNG
  11. Open Advanced Properties
  12. Select Sign Response, Sign Assertion and include Assertion Signature
    Screen Shot 08-27-20 at 02.35 PM.PNG
  13. Under Signature Algorithm, change the value to SHA256 with RSA
  14. Under Digest Algorithm, change the value to SHA256
    Screen Shot 08-27-20 at 02.36 PM.PNG
  15. Click Next, Next Save
  16. Assign the Zoom App to your users in Workspace ONE Access.


Log into Workspace ONE Access as an end user and test the application.  Use the SAML Response Logs in Zoom to help troubleshoot.


Screen Shot 08-27-20 at 02.39 PM.PNG

For updates on this blog and other blogs: Follow @SteveIDM


In Workspace ONE Access, you might have configured additional attributes and would like to populate those attributes from your source of truth such as Okta.


Perhaps its a single attribute:

Screen Shot 08-20-20 at 02.53 PM.PNG

Or maybe you have many attributes:


Screen Shot 08-20-20 at 02.55 PM.PNG


When these attributes are created in Workspace ONE Access, they are created in a custom schema.  The schema is in the following format:




The TENANT will be replaced by your actual tenant name, such as "urn:scim:schemas:extension:workspace:tenant:dsas:1.0".


If you are unsure, I recommend you use Postman to query the user using the GET API. ie. {{tenant_url}}/SAAS/jersey/manager/api/scim/Users?filter=userName%20eq%20%22steve%22


Here is a sample Postman that I'll use as my guideline. Note - this step is not required but I will use it to demonstrate my approach.


Screen Shot 08-20-20 at 02.59 PM.PNG


Now that we know how attributes are stored in Workspace ONE Access, lets configure Okta to send these attributes


  1. Open the Workspace ONE Application in Okta
  2. Click on the Provisioning Tab
  3. Click on " Go to Profile Editor"
    Screen Shot 08-20-20 at 03.05 PM.PNG
  4. Click Add Attribute
    Screen Shot 08-20-20 at 03.07 PM.PNG
  5. Enter the Display Name, Variable Name and External Name exactly how it is created in WS1 Access (ie. objectGUID).
  6. Enter the custom schema as we noted above. Make sure your tenant name is included correctly.
  7. Check the user personal checkbox under Scope
    Screen Shot 08-20-20 at 03.08 PM.PNG
  8. Click Save
  9. Repeat this process for all the attributes you want to provision.
  10. Click on Mappings
  11. Click on the Okta User to VMware Workspace ONE Tab (Note: My image below is slightly different as I've renamed my application)
    Screen Shot 08-20-20 at 03.12 PM.PNG
  12. Select the correct attribute to map. In my environment, I'm mapping the ExternalID to the objectGUID
    Screen Shot 08-20-20 at 03.13 PM.PNG
    Note: You can get the AD objectGUID using: findDirectoryUser().externalId

  13. Click Save Mappings
  14. Click Apply Updates Now

NOTE: This feature in the AirWatch Provisioning Adapter is only available in Preview


Are you using the AirWatch Provisioning Adapter without a locally configured directory in Workspace ONE UEM and when trying to enroll your Windows 10 Devices and you are getting the following error:


Screen Shot 08-17-20 at 11.48 AM.PNG


The reason behind this error is because UEM is checking if the attribute "aadMappingAtribute" is currently set for the particular user received in the request from Azure.  If the attribute is not currently set, UEM will search the directory to retrieve this attribute based on on the value configured in UEM:


Screen Shot 08-20-20 at 12.25 PM.PNG


UEM will retrieve this value from Active Directory (typically) and store this as a binary/hex (ie. 1e7306a8-7eb8-4b6e-a22f-c3e951a5db6e) or as a string depending on the mapping attribute data type.  This is very important because UEM will not successfully map to a user if the value is Base64 encoded. So the following "vZ/lGAC9bUWiA7Egpw5fqg==" is not acceptable.


If this attribute is not set and you don't have an  Enterprise Systems Connector (ACC) with a directory configured, you will receive this error. If you are using the AirWatch Provisioning Adapter, you probably don't have an Enterprise Systems Connector (ACC) and directory configured.


Workspace ONE UEM will allow you to update this attribute manually in the Admin Console:

Screen Shot 08-20-20 at 12.33 PM.PNG


This however is not scalable by any means. Workspace ONE Access is releasing functionality to set this attribute when the user is created by the AirWatch Provisioning Adapter. Unfortunately, UEM will not allow this attribute to be updated via the API so only "CREATE" is supported at this time.


In the AirWatch Provisioning Adapter, you'll soon be able to map this attribute:


Screen Shot 08-20-20 at 12.42 PM.PNG


Please remember that this value can NOT be Based64 encoded.  The following is a guideline of possible values:



aadMappingAttribute in Workspace ONE UEMImmutable ID in AzureAcceptable