Skip navigation
2019

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.