Workspace ONE – Implementing Device Trust solutions

Introduction

As organizations continue to adopt cloud-based solutions, integrating identity and access management with endpoint management is essential for security and operational efficiency. Workspace ONE Device Trust is a conditional access framework within Workspace ONE Access (WS1 Access), which acts as the Identity Provider (IdP), ensuring only Workspace ONE UEM-managed devices can access sensitive federated applications.

To enforce this control, WS1 UEM administrators must also deploy the appropriate authentication profiles and resources to managed endpoints. This integration allows organizations to implement a secure, seamless access strategy, validating both user identity and device trust. Single Sign-On (SSO) capabilities enhance security while streamlining the user experience and reducing the risk of unauthorized access.

Objectives, Architecture Overview, and Prerequisites

The objective of this blog is to configure a WS1 Access Policy that enforces Device Trust for a federated corporate application behind WS1 Access as the IdP, ensuring that only managed devices can access it. This policy will include an authentication rule set targeting three device platforms – iOS, Android, and Windows. In parallel, the blog also covers the deployment of authentication profiles to managed iOS, Android, and Windows devices, respectively, via WS1 UEM. These profiles enable the devices to authenticate and verify their managed status with WS1 Access before being granted SSO access to the federated application, which relies on WS1 Access as its Identity Provider (IdP).

Note: The Device Trust architecture and integration approach depend on an organization’s primary identity access management solution (e.g., Okta, Entra ID, or WS1 Access), even when WS1 UEM is adopted as the endpoint management solution. This blog does not cover other IdP Device Trust implementation methods with WS1. Instead, it is specifically designed for organizations that use WS1 Access as their primary identity and access management solution, securing federated applications behind it.

Please refer to the appropriate product documentation for:

• Okta Device Trust with Workspace ONE
  • iOS & Android device platforms
  • Windows Device Platform
• Entra ID Device Trust with Workspace ONE

The following diagram illustrates the result of the authentication flow into a federated application once the Workspace ONE – Device Trust is implemented.

1. The user enrolls their device (iOS, Android, or Windows) into WS1 UEM.
2. Once the device is managed, WS1 UEM deploys the appropriate authentication profile: Mobile SSO for iOS and Android or a Certificate (Cloud Deployment) profile for Windows. Additionally, WS1 UEM deploys the respective federated application packages to the device.
3. The user launches the federated application and enters their username to initiate authentication.
4. Since the application is federated with WS1 Access as the Identity Provider (IdP), it redirects the authentication request to WS1 Access. WS1 Access evaluates the authentication policy assigned to the federated application and challenges the session based on the device platform, prompting the user to authenticate using the deployed Mobile SSO or Certificate (Cloud Deployment) profile.
5. WS1 Access verifies the metadata from the presented profile against WS1 UEM to confirm that the user identity and managed device ID match. If the validation is successful, WS1 Access completes the authentication and redirects the user back to the federated application with a successful authentication response.
6. The user gains access to the federated application seamlessly, without further authentication prompts.

The following high-level architecture diagram illustrates the two critical integrations between the WS1 Access and the WS1 UEM components to enable the Workspace ONE Device Trust solution (shown in orange).

The objective of this blog is to guide administrators in performing the following in parallel per device platform involved in this blog:

Configure and deploy authentication profiles via WS1 UEM:

Administrators must configure and deploy Mobile SSO profiles for iOS and Android, and a Certificate (Cloud Deployment) profile for Windows devices. These are created as credential profiles in WS1 UEM and aligned with the corresponding WS1 Access authentication methods. The goal is to ensure managed devices receive the necessary profiles and resources to support Workspace ONE Device Trust authentication with WS1 Access. To reduce impact, deployment should follow a phased approach, starting with a WS1 UEM assignment group containing test devices before expanding to all users.

Configure a WS1 Access Policy to enforce Device Trust for a target federated application:

Administrators must enable the Mobile SSO (for iOS/Android) and Certificate (Cloud Deployment) (for Windows) authentication methods in WS1 Access. Activating these methods will not affect existing production authentication flows. Instead, it will make these methods available for adding additional authentication rules to the existing WS1 Access Policy assigned to the application, which represents Device Trust.

Subsequently, administrators will extend the WS1 Access policy (conditional access) currently assigned to the federated application, creating a rule for each device platform. iOS, Android, and Windows will use the Mobile SSO (for iOS/Android) and Certificate (Cloud Deployment) (for Windows), respectively, to validate the Device Trust authentication flows. To avoid production impact, the implementation should follow a phased approach, beginning with a test user group before rolling it out to all users.

To achieve these objectives, the following architectural prerequisites must be in place:

• WS1 UEM and WS1 Access must be integrated together. If they are not yet integrated, administrators can use Omnissa KB – Workspace ONE Integration with UEM to integrate the respective products.
• In the WS1 UEM admin console, the Source of Authentication for Intelligent Hub is currently set to WS1 Access. This enables Hub Services features such as the WS1 Unified Application Catalog.
• Directory Services of WS1 UEM and WS1 Access are configured to synchronize end-users’ AD accounts via LDAP, using the AirWatch Cloud Connector (ACC) and the WS1 Access Connector, respectively.
• User identities and attributes are the same across both environments (WS1 UEM and WS1 Access.) Both components use the on-premises AD as the source for end-user accounts.
• The organization has adopted WS1 Access as the primary Identity Provider (IdP), federating corporate applications within it. Additionally, the WS1 Access Policy (conditional access) must be successfully implemented, including Multi-Factor Authentication (MFA) to enhance security.
• The Password (Cloud Deployment) authentication method is implemented and enforced using the WS1 Access Policy. This authentication process is managed by the WS1 Access Connector(s) for end users. End users authenticate using their domain credentials when logging in to WS1 Access, whether to access the WS1 Access User Portal itself or to gain access to the target federated application.

Additionally, the following requirements must be met to support a phased approach, beginning with testing on the target federated application and a selected group of test AD accounts before a full rollout to all users.

• Administrative access to WS1 UEM as Console Administrator and to WS1 Access as Super Admin.
• Select a federated application behind WS1 Access (as the IdP) to be used for testing. The chosen application should also be available in the Intelligent Hub app catalog on endpoint devices. In this blog, the Terranova Training web application is used and configured to display under the Apps tab in Intelligent Hub for entitled users’ endpoint devices.
• Create a test AD account that represents the role of a real user within the organization. This test account must also exist as an account in the selected federated application. Additionally, it must be synchronized with both WS1 UEM and WS1 Access, mirroring the experience of a regular end user. In this blog, the created test AD account is “johnny.test.”
• Ensure the test AD account can successfully authenticate via WS1 Access as the IdP and access the target federated application using either the default WS1 Access Policy or a customized WS1 Access Policy specifically designated for the application.
• Android Enterprise is integrated with WS1 UEM.
• Ensure you have iOS, Android, and Windows devices available for testing. Each device should be enrolled in WS1 UEM using the created test AD account.

Integration Summary

In the Configuration section, we will dive into the specifics of each integration step. However, because the configurations will be performed in both admin consoles in parallel (WS1 UEM and WS1 Access) and applied across three device platforms (iOS, Android, and Windows), the Configuration section will be structured by platform. This approach ensures clear and organized implementation, making validation more straightforward.

The sequence of integrations and the high-level objectives we will be achieving along the way are:

Preparing Local Groups in WS1 UEM and WS1 Access for Device Trust Validation:

The term “a selected group of testers” refers to a set of end-user accounts designated for testing throughout this blog. In WS1 UEM, administrators can deploy the necessary authentication profiles and resources for Device Trust authentication to an assignment group which targets the selected group of testers and their devices. In WS1 Access, the Device Trust conditional access policy will target this set of users to ensure authentication is processed correctly for these testers.

For the production rollout, administrators will then extend these configurations to a broader group representing all users in the organization, following the same deployment approach in both WS1 UEM and WS1 Access.

To facilitate testing, we will create these native groups in both WS1 UEM and WS1 Access, avoiding unnecessary modifications in Active Directory. Once testing is complete and the production rollout is finalized, these testing groups can be deleted to maintain a clean environment.

However, test accounts must still be Active Directory-sourced and synchronized to WS1 UEM and WS1 Access using the organization’s standard sync method. For this blog, the membership of these test groups will consist only of the test account, “johnny.test” created as outlined in the Prerequisites section.

This section outlines the creation of two local groups and their membership structure in both WS1 UEM and WS1 Access:

• “Test – Device Trust devices” group (WS1 UEM assignment group): Targets the test users and contains their test devices.
• “Test – Device Trust users” group (WS1 Access local user group): Represents a collection of the test account(s) that will be assigned to the WS1 Access Policy for Device Trust.

Configure iOS Device Trust in Workspace ONE

In this section, we will configure WS1 Access and WS1 UEM to enable Device Trust authentication for iOS devices. This involves deploying the necessary SSO profiles and access policies to ensure only managed iOS devices can authenticate to the federated application.

WS1 Access Configuration

Begin by logging into the WS1 UEM console to retrieve the Workspace ONE UEM Certificate Authority first. Then proceed in WS1 Access, configure the following:

• Enable and configure the Mobile SSO (iOS) authentication method for the tenant and associate it with the organization’s currently integrated Directory Services, making it available for use in the WS1 Access Policy for Device Trust.

WS1 UEM Configuration

Deploy the following resources to the “Test – Device Trust devices” assignment group:

• Create and deploy a profile named “iOS – Mobile SSO” for the iOS platform: This SSO profile will contain three configurations: Credentials, SCEP, and Single Sign-On. This profile will enable seamless single sign-on (SSO) authentication for managed iOS devices with the WS1 Access’ Mobile SSO (for iOS) authentication method.

WS1 Access Configuration 2

Configure a WS1 Access Policy that is currently assigned to the federated application. In this blog, the Terranova federated application has a designated WS1 Access policy assigned to it. Currently, this policy enforces authentication using a password and MFA. We will extend this existing policy by adding a new rule to use the Mobile SSO (iOS) authentication method, specifically targeting the “Test – Device Trust users” group only and set it with higher priority in the authentication order. If no policy is currently assigned to the target federated application, administrators should create one before proceeding.

• Configure and apply the Mobile SSO (iOS) authentication method against the “Test – Device Trust users” group.
• Target the policy to iOS devices to enforce authentication for only iOS devices.

Configure Android Device Trust in Workspace ONE

Unlike iOS, Android requires additional configuration within WS1 UEM due to its reliance on the Omnissa Tunnel for SSO authentication.

Without a properly configured Tunnel infrastructure in WS1 UEM and an activated Tunnel app on the Android device, Device Trust authentication will not function.

Therefore, the Omnissa Tunnel app must be added to WS1 UEM through Google Play Store integration and configured as needed prior to deployment to target devices. It’s important to note that the Tunnel app must be activated by the end user to enable Device Trust authentication. This is a one-time activation process: when the user opens the app for the first time, they must proceed through legal disclaimers and device notification prompts. Once completed, the Tunnel app will run silently in the background to support secure Device Trust authentication via the WS1 Access Mobile SSO (for Android) authentication method.

To streamline the end-user experience during this initial activation, administrators can refer to the appropriate Omnissa Knowledge Base (KB) article to disable all or selected privacy prompts. This eliminates unnecessary dialogs on first launch for activation purposes. In this blog, all prompts will be disabled to optimize the user experience. However, these configuration keys are optional and should be implemented based on the organization’s privacy policy requirements.

WS1 UEM Configuration

Deploy the following resources to the “Test – Device Trust devices” assignment group:

• Omnissa Tunnel Configuration and Deployment:
  • If the Omnissa Tunnel is not yet deployed in your WS1 UEM environment, set up a dummy Tunnel infrastructure. After setting up, obtain the Tunnel’s Client Authentication certificate, which will be required later to configure the Mobile SSO (for Android) authentication method in the WS1 Access Configuration section.
  • If the Omnissa Tunnel is already deployed in your environment, simply download the Tunnel’s Client Authentication certificate from the WS1 UEM console for use in WS1 Access.
• Omnissa Tunnel and Google Chrome application configuration and deployment:
  • Add, configure, and deploy the Omnissa Tunnel application.
  • Android Google Chrome application deployment: In this blog, since SAML authentication for the Terranova app on Android devices is performed through the Google Chrome browser – and because the browser must be entitled to use the Omnissa Tunnel Device Traffic Rules in a later section, administrators must ensure a browser is deployed to the test devices.

Note: For simplicity, this blog assumes that the Chrome app has already been deployed to the Android test devices. If the WS1 UEM environment does not currently manage a browser on Android devices, administrators must deploy one (e.g., Google Chrome) before proceeding to the subsequent configuration steps

• Configure the Omnissa Tunnel’s Device Traffic Rule:
  • Set up a Per-App VPN rule to allow the federated application package and/or a browser application (Chrome, in this blog) to route traffic through the Tunnel. This enables the app to securely communicate with the WS1 Access certificate authentication proxy server, which is essential for successful Device Trust authentication.
• Create and deploy a profile named Android – Mobile SSO to the Android platform: This is a WS1 UEM’s Tunnel profile that applies the Per-App Tunnel traffic rule configured above. It enables seamless SSO authentication for managed Android devices.
• Associate the Android – Mobile SSO profile for the Android platform with the federated application and/or browser app (e.g., Chrome in this blog) on the device.

WS1 Access Configuration

In WS1 Access, configure the following:

• Enable and configure the Mobile SSO (for Android) authentication method for the tenant and associate it with the organization’s currently integrated Directory Services, making it available for use in the WS1 Access Policy for Device Trust.
• Configure the WS1 Access Policy that is currently assigned to the federated application. As a recap, the Terranova federated application has a designated WS1 Access Policy assigned to it. By this stage, we have added a high-priority rule to this policy targeting iOS devices enrolled under the “Test – Device Trust users” group. This rule challenges these users with Mobile SSO (for iOS) authentication and was successfully validated in the iOS section.

We will now extend this policy by adding a new rule targeting Android devices. This rule will apply only to the same “Test – Device Trust users” group and will enforce Mobile SSO (for Android) authentication, with a priority set above the existing rules.

• Create and apply the Mobile SSO (for Android) authentication method against the “Test – Device Trust Users” group.
• Target Android devices to enforce authentication for only Android devices.

Configure Windows Device Trust in Workspace ONE

In this section, we will configure WS1 Access and WS1 UEM to enable Device Trust authentication for Windows devices. This involves deploying the necessary SSO profiles and access policies to ensure only managed Windows devices can authenticate to the federated application.

WS1 Access Configuration

Begin by logging in to the WS1 UEM console to retrieve the Workspace ONE UEM Certificate Authority, then in WS1 Access, configure the following:

• Enable and configure the Certificate (Cloud Deployment) authentication method for the tenant and associate it with the organization’s currently integrated Directory Services, making it available for use in the WS1 Access Policy for Device Trust.

WS1 UEM Configuration

Deploy the Windows platform – Certificate (Cloud Deployment) Profile to the “Test – Device Trust devices” assignment group. This is a Certificate Enrollment Protocol (SCEP) profile that automates the deployment of user identity certificates to WS1 UEM-managed Windows devices.

WS1 Access Configuration 2

Configure the WS1 Access Policy that is currently assigned to the federated application: Extend the WS1 Access Policy assigned to the Terranova app by adding a new rule targeting Windows devices. This rule will apply only to the same “Test – Device Trust users” group and will enforce Certificate (Cloud Deployment) authentication, with a priority set above the existing rules.

• Apply the Certificate (Cloud Deployment) authentication method against the Test – Device Trust Users Group.
• Target Windows devices to enforce authentication for only Windows devices.

Production Rollout: Workspace ONE – Device Trust.

For Production Rollout, administrators are to perform the following:

• WS1 UEM, deploy the iOS – Mobile SSO, Android – Mobile SSO, and Windows – Certificate – Cloud Deployment profiles to an assignment group representing all managed devices in the organization.

Note: The next step will enforce Mobile SSO (for iOS/Android) and Certificate (Cloud Deployment) for Windows within the WS1 Access Policy assigned to the application. Administrators must ensure all WS1 UEM-managed iOS, Android, and Windows devices have received their respective authentication profiles before proceeding to avoid loss of access to the federated application.

• Enforce the WS1 Device Trust framework for the selected federated application:

To extend the WS1 Access policy for the federated application to all users in the organization, administrators can choose between two approaches:

• Option 1: Retain platform-specific rule.
• • Remove the “Test – Device Trust users” group from each of the existing rules previously created for testing. By doing this, administrators ensure that all users across the organization must use WS1 UEM-managed devices (iOS, Android, or Windows) to access the federated application. Otherwise, apply each rule to a WS1 Access group representing all users in the organization.
  • Delete the current rule that enforces Password + MFA authentication.
  • Benefit: Maintains clear, platform-specific policy rules, offering flexibility and easier troubleshooting for each device type.

• Option 2: Consolidate into a Single Catch-All Rule.
• • Delete the three platform-specific test rules.
  • Modify the existing Password + MFA rule to instead use a chained authentication approach: Mobile SSO (for iOS), if that fails, try Mobile SSO (for Android), if that fails, fall back to Certificate (Cloud Deployment).
  • Apply this rule to all users by removing any group restriction or assigning it to a group that contains all users.
  • Set “and the user accessing content from” to All Device Types.
  • Benefit: Simplifies policy management by consolidating logic into a single rule that covers all platforms and users.

Note: This blog will cover the configuration steps only for Option 2 under the Configuration > Production Rollout section.

Configuration

The first step is to prepare local Groups in WS1 UEM and WS1 Access for Device Trust implementation and validation. As per prerequisites, at this stage, the test AD account, “johnny.test”, representing a standard organizational user, has already been synchronized and exists in both WS1 components. Additionally, in WS1 Access, the “johnny.test” account has been granted access entitlements to the selected federated application. On the application side, the “johnny.test” account also exists, completing the necessary user provisioning for Device Trust implementation and validation readiness.

Preparing Local Groups in WS1 UEM and WS1 Access for Device Trust Validation.

Create the “Test – Device Trust devices” assignment group in WS1 UEM:

Step 1: Log in to WS1 UEM admin console, go to Groups & Settings > Assignment Groups > Add Assignment Group.

In the Create New Smart Group screen, under Name, type “Test – Device Trust Devices” or a descriptive name.

Under Choose Type, select DEVICES OR USERS.

Under Users, input “johnny.test” > Add > Save to add the assignment group.

Step 2: Enroll an iOS device, an Android device, and a Windows device into WS1 UEM using the “johnny.test” account and validate that these devices are members of this assignment group.

Create the “Test – Device Trust users” local group in WS1 Access :

Step 1: Log in to the WS1 Access admin console > Accounts > User Groups > Add Group.

Under the Group Information section, input “Test – Device Trust Users” for the Group Name and provide a description if desired in the Description field.

Scroll down and under the User Group section, input “johnny.test” and the system will perform a dynamic search > Click on the “johnny.test” account for the account to be a member of this group > Save the group configuration.

Step 2: Find the “Test – Device Trust users” group and validate that the “johnny.test” account is a member of this group by clicking on the Users tab of this group.

Configure iOS Device Trust in Workspace ONE

WS1 Access Configuration:

Step 1: Begin by logging into the WS1 UEM console and retrieving the Workspace ONE UEM Certificate Authority. This certificate file will be required later when enabling the Mobile SSO (iOS) authentication method in WS1 Access.

Log in to the WS1 UEM admin console > Groups & Settings > All Settings > under System, expand Enterprise Integration.

Choose Workspace ONE Access > Configuration > Under the Certificate section, click Enable. The page will then show certificate provisioning as shown in the screenshot below.

Click Export > the certificate is downloaded onto the computer. Make a note of the location of the certificate file.

Step 2: Log in to the WS1 Access admin console > Integrations > Authentication Methods.

On the list, locate and click on the Mobile SSO (for iOS) > Configure.

Toggle on Enable KDC Authentication > under Root and Intermediate CA Certificates, upload the exported cert file from step 1 > Leave everything else as default > then Save.Head back to Integrations > on the left menu, click on Identity Providers > Click on Built-In.

Under the Users section, ensure there is a check mark for the current integrated Directory Services in the environment.

Under the Authentication Methods section, check the Mobile SSO (for iOS). This action enables the Mobile SSO (for iOS) Authentication Method for users from Active Directory. As noted, this step only makes the authentication method available for directory-sourced users in a WS1 Access Policy for Device Trust, and it does not affect the current authentication flow.

Scroll down to the KDC Certificate Export section and click the Download Certificate button to export a copy of the KDC certificate. This certificate will be used to create the Mobile SSO profile for the iOS device platform in WS1 UEM.

WS1 UEM Configuration:

Step 1: Create and deploy the iOS – Mobile SSO profile for the iOS platform:

Log in to the WS1 UEM admin console > Resources > Profiles & Baselines > Profiles > Add > Add Profile.

On the Add Profile pop-up> choose Apple iOS.

Leave the default for Management Type: Imperative and Context: Device.

Name the Profile – iOS – Mobile SSO or a descriptive name.

Scroll down and locate the Credentials payload> Add.

For Credential Source, select Upload.

Under Certificate, click on Choose File > Upload the KDC cert exported from WS1 Access earlier > Attach Certificate. ie. KDC-root-cert.cer.

Minimize the Credentials section and on the left menu, locate the SCEP section > Add.

For Credential Source, select AirWatch Certificate Authority.

For Credential Authority, select AirWatch Certificate Authority.

For Certificate Template, select Single Sign-On.

Minimize the SCEP section and on the left menu, locate the Single Sign-On section > Add.

For the account name, enter Kerberos or a desired friendly name.

For the Kerberos Principal Name, click + and select {EnrollmentUser}.

For the realm name, enter the realm name of your WS1 Access tenant in all caps. (In this blog, it is VMWAREIDENTITY.CA). The realm name can be found in the domain of your Access tenant URL (eg: VMWAREIDENTITY.COM, VMWAREIDENTITY.CO.UK, VMWAREIDENITY.DE, VIDMPREVIEW.COM)

For Renewal Certificate, choose SCEP.

For URL Prefixes, input the full name of the WS1 Access tenant.

Minimize the Single Sign-On section and validate that the three configurations of this profile are highlighted in green> Next.

Under the Assignment page, input and select the “Test – Device Trust devices” assignment group > Save & Publish.

Step 2: Locate the managed iOS device under the “johnny.test” account and validate that the iOS – Mobile SSO profile has landed on the device.

On the iOS device itself, go to Settings > General > VPN & Device Management > click on Workspaces Services > More Details > validate the Mobile SSO profile has landed as shown below.

WS1 Access Configuration 2

Step 1: Configure and apply the Mobile SSO (for iOS) authentication method against the “Test – Device Trust users” group within the current WS1 Access Policy assigned to the Terranova app:

Log in to WS1 Access admin console, go to Resources > Policies.

Under Custom App Policies > Locate the current policy assigned to the Terranova app > click on the 3 dots > Edit.

On the Edit Policy page, click on Configuration > Add Policy Rule.

On the Add Policy rule page, set the following > then save:

Check: And the user accessing content from: choose iOS

Check: And the user belongs to group(s): type and select Test – Device Trust users

Then the user may authenticate using: choose Mobile SSO (for iOS)

Optional if desired: Expand Advanced Properties, under Custom Error Message, input a friendly custom error message to display when the iOS is not managed by WS1 UEM and attempt to gain access to the federated application. i.e., Allow access from WS1 Managed only.

The new rule is created and appears at the bottom of the rule set > Drag the rule to the top of the list to be the top priority in the authentication evaluation order > Next > Review the configuration > then Save.

Initial validation of the iOS – Workspace ONE Device Trust

On the iOS device enrolled under the “johnny.test” account, launch the Hub client > Apps > All Apps > click on the Terranova web application.

Safari opens and displays the authentication screen of the app > input in the username to start the authentication process.

The page is redirected to WS1 Access for authentication > Input “johnny.test” and hit Next > WS1 Access evaluates the Mobile SSO (for iOS) authentication session and the user gains access to the Terranova app after a successful authentication with no password required.

Administrators can leverage WS1 Access Audit event logs to troubleshoot any authentication failure issues. For successful Mobile SSO (for iOS) authentication, the log will contain an authentication sequence as shown below.

Click on View Details on the line with LOGIN (MobileSSO (for iOS)) to view more details. A successful Mobile SSO (for iOS) authentication has the following.

To validate that a non-WS1 UEM-managed iOS device cannot access the federated application, administrators can either unenroll the current test device or temporarily remove the iOS – Mobile SSO profile from the device via WS1 UEM. For simplicity, this blog will proceed with removing the profile from the test device.

Attempt to access the Terranova app web app via the Hub client on the iOS device again > the user receives the Custom Error message according to our configuration earlier (Note: It is recommended to clear the cache of the browser on the device to trigger a new authentication process immediately.) This simulates a scenario where the iOS device is unmanaged, resulting in a failed Device Trust authentication, confirming that access is correctly restricted to managed devices only.

Validate the WS1 Access Audit Events Logs, administrators will see the failure in Mobile SSO (for iOS) authentication.

Configure Android Device Trust in Workspace ONE

WS1 UEM Configuration:

This blog assumes no existing Omnissa Tunnel configuration in the environment. Therefore, step 1 below provides instructions to set up a dummy Tunnel in WS1 UEM specifically for testing purposes. If the WS1 UEM environment already has a functioning Omnissa Tunnel deployed, please skip step 1 and proceed directly to step 2.

Step 1: Set up Omnissa Tunnel in WS1 UEM: Log into WS1 UEM admin console > Groups & Settings – All Settings > System > Enterprise Integration > Omnissa Tunnel. As this is the first time configuration, select Configuration. If required, click on Override.

Configure the following on the New Tunnel Configuration page > then Save.

Deployment Type: Basic

Name: Provide a friendly name. i.e MobileSSO Tunnel

Hostname: Provide a dummy name in the format of a web URL. i.e. mobilesso.android.com

Port: 8443

Step 2: Expand the Client Authentication section of the configured Omnissa Tunnel. Under Client Certificate, click Export to download the Tunnel authentication certificate (i.e., TunnelDeviceRootCertificate.cer). This certificate will be used later during the WS1 Access configuration section for enabling the Mobile SSO (for Android) authentication method. Be sure to take note of the certificate’s download location on your computer.

Step 3: Omnissa Tunnel and Federated Application Configuration and Deployment:

In the WS1 UEM admin console, navigate to Resources > Apps > Native Apps > click on Public tab > Add Application > under Add Application screen, select Android for Platform > input Omnissa Tunnel app from the Google Play Store under the Name field > Next.

Locate and choose the Omnissa Tunnel app > Select.

At the Edit Application – Omnissa Tunnel screen, click Save & Assign > Under Omnissa Tunnel – Assignment screen, configure the following for Distribution:

Name: Provide a friendly name. i.e., Omnissa Tunnel – Device Trust devices.

Description: Provide a friendly description if necessary.

Assignment Groups: input and select “Test – Device Trust devices” assignment group.

App Delivery Method: Auto

Optional: Apply the Tunnel app configuration to disable all privacy and other prompts upon first launch by the end user:

Click on Application Configuration on the left menu, Enable Send Configuration > a list of configurable keys appears, configure the desired options (i.e. Enable or Disable specific prompts). In this blog, we disable all prompts as shown below.

Click Create > Save > Publish to deploy the Tunnel application.

Android Google Chrome browser deployment: For simplicity, this blog already has Google Chrome deployed to Android devices. Otherwise, administrators must deploy one (e.g., Google Chrome) or a relevant mobile app package of the federated app before proceeding to the subsequent configuration steps.

Step 4: Configure Omnissa Tunnel’s Per-App VPN Device Traffic Rule: On the left menu, navigate to Security > Device Traffic Rules.

Hit Add to create a new Device Traffic Rule.

Assignment Name: Provide a friendly name. i.e. Android Mobile SSO.

Tunnel mode: choose Per Application.

Then click on the Add Rule button and configure the following as shown below > then Save.

Application: select Google Chrome – Android (Otherwise, select a browser that currently deploys to Android devices fleet) and if applicable, the federated mobile app package deployed in the environment.

Action: choose Proxy.

Web Proxy: input certproxy.vmwareidentity.ca:5262 (note: if the WS1 Access in the environment has the domain vmwareidentity.com (USA), input certproxy.vmwareidentity.com:5262 instead, or certproxy.vidmpreivew.com:5262 for test tenants.

Destination: input the WS1 Access URL (i.e. companydomain.vmwareidentity.ca).

Step 5: Configure and deploy the Android – Mobile SSO profile:

Navigate to Resources > Profiles & Baselines – Profiles > Add – Add Profile.

On the Add Profile pop up > choose Android.

Name the Profile: Android – Mobile SSO or a desire friendly name.

Scroll down and locate VPN > Add.

Connection Type: choose Workspace ONE Tunnel.

Connection Name: Provide a friendly name (i.e., Android – Mobile SSO).

Tunnel Configuration: choose the Omnissa Tunnel configured from step 1 (i.e., MobileSSO Tunnel).

Device Traffic Rules: select the Device Traffic Rules configured from step 4 (i.e., Android Mobile SSO Device Traffic Rule).

Hit Next > under the Assignment page, input the “Test – Device Trust devices” assignment group > under Deployment, set Assignment type to Auto > and Save & Publish.

Step 6: Associate the Android – Mobile SSO profile with the federated app package (if deployed in the environment) and/or the Chrome for Android browser:

Navigate to Resources > Apps – Native Apps > Public.

Navigate to Resources > Apps – Native Apps > Public.

Search for Google Chrome > checkmark the app > Select an assignment that includes the test users.

Under Tunnel, enable Managed Access > under Android (Custom DPC), select Android – Mobile SSO profile configured from step 5.

Click Save > Publish.

WS1 Access Configuration:

Step 1: Enable and configure the Mobile SSO (for Android) authentication method:

Log in to WS1 Access admin console > Integrations > Authentication Methods.

On the list, locate and click on the Mobile SSO (for Android) > Configure.

Enable Certificate Adapter by turning on the switch.

Under Root and intermediate CA certificates, click on Select File…> Upload the certificate downloaded from step 2 of the WS1 UEM Configuration section (i.e. TunnelDeviceRootCertificate.cer).

User Identifier Search Order, select upn | subject, or an alternate use according to your AD configuration.

Leave everything else default > Save.

Head back to Integrations > on the left menu, click on Identity Providers > Click on Built-In.

Under the Users section, ensure there is a check mark for the current integrated Directory Services in the environment.

Under the Authentication Methods section, check Mobile SSO (for Android). This action enables Mobile SSO (for Android) Authentication Method for the users from Active Directory.

Step 2: Extend the current WS1 Access policy assigned to the Terranova app by adding a new rule targeting Android devices:

Log in to WS1 Access admin console, go to Resources > Policies.

Under Custom App Policies > Locate the current policy assigned to Terranova app > click on the 3 dots > Edit.

On the Add Policy rule page, set the following > then Save:

And the user accessing content from: choose Android.

And the user belongs to group(s): type and select Test – Device Trust users.

Then the user may authenticate using: choose Mobile SSO (for Android).

(Optional if desired) Expand Advanced Properties, under Custom Error Message, input a friendly custom error message to display when the Android is not managed by WS1 UEM and attempt to gain access to the federated application. i.e., Allow access from WS1 Managed only.

The new rule is created and appears at the bottom of the rule set > Drag the rule to the top of the list to be the top priority in the authentication evaluation order > Next > review the configuration > and then save.

Initial validation of the Android Workspace ONE Device Trust

On the Android device enrolled under “johnny.test” account, open the Hub client > Apps > All Apps > Locate and open the Terranova web app.

Chrome opens and displays the authentication screen of the app > input the username to start the authentication process.

The page gets redirected to WS1 Access for authentication > input “johnny.test” and hit Next > WS1 Access evaluates the Mobile SSO (for Android) authentication session and the user gains access to the Terranova app after the device is evaluated and compliant.

Administrators can leverage WS1 Access Audit event logs to troubleshoot any authentication failure issues. For successful Mobile SSO (for Android) authentication, the log will contain an authentication sequence as shown below.

Click on View Details on the line with LOGIN (MobileSSO (for Android)) to view more details. A successful Mobile SSO (for Android) authentication has the following.

To validate that a non-WS1 UEM-managed Android device cannot access the federated application, administrators can either unenroll the current test device or temporarily remove the Mobile SSO (Android) profile from the device via WS1 UEM. For simplicity, this blog will proceed with removing the profile from the test device.

Attempt to access the Terranova app web clip on the Android device again > the user receives the Custom Error message according to our configuration earlier (recommend clearing the cache on the Chrome browser on the device to trigger an immediate new authentication process). This simulates a scenario where the Android device is unmanaged, resulting in a failed Device Trust authentication, confirming that access is correctly restricted.

Validate the WS1 Access Audit Events Logs, administrators will see the failure in Mobile SSO (for Android) authentication.

Configure Windows Device Trust in Workspace ONE

WS1 Access Configuration:

Step 1: Begin by logging into the WS1 UEM console and retrieving the Workspace ONE UEM Certificate Authority details. This certificate file will be required later when enabling the Certificate (Cloud Deployment) authentication method in WS1 Access.

Log in to the WS1 UEM admin console > Groups & Settings > All Settings > under System, expand Enterprise Integration.

Choose Workspace ONE Access > Configuration > Under Certificate section, click Enable. The page will then show certificate provisioning as the screenshot below.

Click Export > the certificate is downloaded onto the computer. Make a note of the location of the certificate file.

Step 2: Log in to the WS1 Access admin console > Integrations > Authentication Methods

On the list, locate and click on the Certificate (Cloud Deployment) > Configure.

Toggle on Enable Certificate Adapter > under Root and Intermediate CA Certificates, upload the exported cert file from step 1. You will see the uploaded CA Certificates with the name CN=<WS1UEMOGNAME>.

Leave everything else with default settings > then Save. Alternatively, administrators can use the table in this Omnissa KB to configure the desired authentication option.

Head back to Integrations > on the left menu, click on Identity Providers > Click on Built-In.

Under the Users section, ensure there is a check mark for the current integrated Directory Services in the environment.

Under the Authentication Methods section, check Certificate (Cloud Deployment). This action enables Certificate (Cloud Deployment) Authentication Method for users from the Active Directory. As noted, this step only makes the authentication method available for directory-sourced users in a WS1 Access Policy for Device Trust; it does not affect the current authentication flow.

WS1 UEM Configuration:

Step 1: Configure and deploy the Windows – SSO – Certificate Cloud Deployment Profile for Windows Platform:

Log in to the WS1 UEM admin console > Resources > Profiles & Baselines – Profiles > Add > Add Profile.

On the Add Profile pop-up > choose Windows > on Select Device Type page, select Windows > on Select Context page, select User Profile.

Name the Profile: Windows – SSO – Certificate Cloud Deployment or a descriptive name.

Under Smart Groups, input and select the “Test – Device Trust devices” assignment group > Click SCEP on the left menu.

Configure the following:

For Credential Source, select AirWatch Certificate Authority.

For Certificate Authority, leave as is – AirWatch Certificate Authority.

For Certificate Template, select Single Sign-On.

For Key Location, select TPM Required (Note: this is the most secure way to store the certificate keys on the device).

Click Save & Publish.

Step 2: Validate the Certificate (Cloud Deployment) profile has landed on the device.

On the Windows device itself, Launch MMC > File – Add/Remove Snap-in… > Certificate – Add > select My user account > Finish > OK

Validate that the certificate issued to “johnny.test” appears under the personal certificate store.

WS1 Access Configuration 2

Step 1: Configure and apply the Certificate (Cloud Deployment) authentication method against the “Test – Device Trust users” group within the current WS1 Access Policy assigned to the Terranova app:

Log in to WS1 Access admin console, go to Resources > Policies.

Under Custom App Policies > Locate the current policy assigned to Terranova app > click on the 3 dots > Edit.

On the Edit Policy page, click on Configuration > Add Policy Rule.

On the Add Policy rule page, set the following > then Save:

Check: And the user accessing content from: choose Windows 10+

Check: And the user belongs to group(s): type and select Test – Device Trust users.

Then the user may authenticate using: choose Certificate (Cloud Deployment).

Optional if desired: Expand Advanced Properties, under Custom Error Message, input a friendly custom error message to display when the iOS is not managed by WS1 UEM and attempt to gain access to the federated application. i.e., Allow access from WS1 Managed only.

The new rule is created and appears at the bottom of the rule set > Drag the rule on top of the list to be the top priority in the authentication evaluation order > Next > Review the configuration > then Save.

Initial validation of the Windows – Workspace ONE Device Trust

On the Windows device enrolled under “johnny.test” account, access the Omnissa Intelligent Hub client > Apps tab > All Apps> Click on Terranova web app.

Chrome opens and displays the authentication screen of the app > input the username to start the authentication process.

The page gets redirected to WS1 Access for authentication > WS1 Access evaluates the Certificate (Cloud Deployment) authentication session > a certificate selection pop-up > the user chooses the “johnny.test” cert > the user gains access to the Terranova app after a successful authentication.

Administrators can leverage WS1 Access Audit event logs to troubleshoot any authentication failure issues. For successful Certificate (Cloud Deployment) authentication, the log will contain an authentication sequence as shown below.

Click on View Details on the line with LOGIN (Certificate (Cloud Deployment)) to view more details. A successful Certificate (Cloud Deployment) authentication has the following.

To validate that a non-WS1 UEM-managed Windows device cannot access the federated application, administrators can either un-enroll the current test device or temporarily remove the Certificate (Cloud Deployment) profile from the device via WS1 UEM. For simplicity, this blog will proceed with removing the profile from the test device.

Attempt to access the Terranova app on the Windows device again via the Intelligent Hub client > user receives the Custom Error message according to our configuration earlier (recommend to clear Chrome browser cache on the device). This simulates a scenario where the Windows device is unmanaged, resulting in a failed Device Trust authentication, confirming that access is correctly restricted.

Validate the WS1 Access Audit Events Logs, administrators will see the failure in Certificate (Cloud Deployment) authentication.

Production Rollout: Workspace ONE – Device Trust

Step 1: In WS1 UEM, deploy the iOS – Mobile SSO, Android – Mobile SSO, and Windows – Certificate – Cloud Deployment profiles to an assignment group representing all managed devices in the organization.

Note: As a reminder, administrators must ensure all WS1 UEM-managed iOS, Android, and Windows devices have received their respective authentication profiles before proceeding to the next step avoid loss of access to the federated application.

Step 2: Enforce the WS1 Device Trust framework for the selected federated application by consolidating the WS1 Access Policy assigned to the Terranova app into a Single Catch-All Rule.

Log in to WS1 Access admin console, go to Resources > Policies.

Under Custom App Policies > Locate the current policy assigned to Terranova app > click on the 3 dots > Edit > Configuration.

Click on the X on each of the constructed test rules as shown below.

Then, click on the existing production rule that is challenging for Password + MFA > edit the policy to the configuration as shown below.

Save > Next > Review the policy configuration > Save. That’s it! Users can access their federated application easily (using SSO) and administrators can ensure that this occurs only if their device is managed by WS1 UEM.