PingOne SCIM Integration

Purpose

In this article, I am going to walk through setting up Workspace ONE with PingOne as an authoritative identity provider (IDP). With the introduction of Omnissa Indentity Services (OIS), Workspace ONE now supports generic SCIM 2.0 identity providers, which I will elaborate on further below. 

Notes/Assumptions

In this guide, I am going to operate under the following assumptions in terms of environment: 

• Omnissa Identity Services (OIS) will be used for SCIM 2.0 provisioning and for SAML auth. This service is available for Omnissa Cloud Services-connected tenants, which may not be everybody at time of writing. Further, generally OIS is only available to Workspace ONE tenants with no prior directory configurations in both Workspace ONE UEM and Access. If you need this cleared, you may need to contact support. 

• Users in PingOne need to have all necessary attributes for Workspace ONE (ex. externalId) that may not already be populated in the directory. Information on required attributes can be found on this doc.

• This guide assumes no on-premise directory (no Active Directory) and users are solely sourced from Ping One (SaaS)

• In terms of acronyms, OIS refers to Omnissa Identity Services (formerly VMware Identity Services, or Broker), OIDC refers to the OpenID Connect protocol, and Ping generally refers to the PingOne SaaS application

Setting up SCIM Provisioning and Federation between PingOne and Workspace ONE (OIS) 

1. Create the SCIM connection between PingOne and Workspace ONE

   1. In the Ping console, go to Integrations - Provisioning - New Connection - Identity Store (source documentation from Ping, for reference). OIS will provide the SCIM base URL and bearer token here. Be sure to test connection. 

2. Create provisioning rule in Ping (this will trigger the provisioning to Workspace ONE)
a. Change the attribute mapping in the provisioning rule to align with OIS attribute mapping. Below is a screenshot of what I used. 

b. By default, the provisioning rule will be disabled. Leave it disabled until the OIS configuration is completed. 

3. Create the OIDC application for Workspace ONE in Ping, complete the OIS wizard

a. Create a new OIDC application in Ping and name appropriately

b. Copy and paste the redirect URI from OIS to Ping

c. Copy and paste the Client ID and Client Secret from OIS to Ping

d. Copy and paste the OIDC discovery endpoint URL from Ping to the configuration URL field in OIS

e. Set the "Workspace ONE User Identifier Attribute" in OIS to be username 

f. In Ping, set the "sub" attribute in the OIDC application to map to username

g. Finish the OIS directory creation wizard. Go back and enable the provisioning rule in Ping. Monitor OIS and Ping for any provisioning errors. 

h. Enable the OIDC application you created in Ping (as apps created in Ping are disabled by default) 

i. Test the authentication flow by authenticating against the Workspace ONE Access tenant / enrolling a device in Workspace ONE UEM

Setting up Device Trust / Conditional Access between Workspace ONE and Ping 

1. Add Workspace ONE as a third party IdP in Ping

a. Integrations - External IdP's - Add Provider

b. Import the IdP metadata from Workspace ONE Access (this can be found in Access under Resources - Settings - SAML Metadata)

c. For attributes, below are the ones that I used - 

2. Create the application for Ping in Workspace ONE Access

a. This is for the situations when we are going to leverage WS1 Access as the IdP (for those “protected apps” to check for a certificate on device + device compliance)

b. For the configuration, the ACS Endpoint will be copied from Ping and pasted into WS1 Access for the Single Sign On URL, Recipient URL. The SP Entity ID from Ping will be pasted into WS1 Access for the Application ID. In Access, leave username format unspecified, and value to be {user.userName}.

c. Expand Advanced Properties and add the following custom attribute mapping: 

i. username should map to value ${user.userName}

ii. email should map to value ${user.email}

3. Configure Mobile SSO (this is meant to be summary in nature, as this process is documented elsewhere, for instance, in this blog post. It is dated but the process is largely still the same) 

a. For iOS 

i. Enable certificate provisioning in Workspace ONE UEM if not done already (System - Enterprise Integration - Workspace ONE Access - Configuration). Export the root certificate from here.

ii. Push a device SCEP profile leveraging the AirWatch CA

iii. Push an SSO Extension payload specifying Workspace ONE Access and the tenant URL for Workspace ONE Access

iv. In Workspace ONE Access, turn on the “Mobile SSO for Apple” authentication method, and import the certificate you downloaded from step 3ai above. Then click save.

b. For Android

i. Set up tunnel with a per-app config. The URL of the tunnel endpoint doesn’t matter (dummy.dbabcockdev.com) but set a per-app vpn to proxy traffic from your Workspace ONE Access tenant URL to certproxy.workspaceair.com:5443 (or appropriate domain, such as vidmpreview.com).

ii. Download the client certificate from the tunnel configuration in Workspace ONE UEM.

iii. Add the browser of choice (like chrome) as a managed app and then assign the per-app VPN profile to the app.

iv. Push the Tunnel applications to Android devices as well.

v. In Workspace ONE Access, turn on the “Mobile SSO for Android” authentication method, and import the certificate you downloaded from step 3bii above.

4. Create the access policy in Workspace ONE Access

a. Create a new access policy (don’t use the default one - that will still be used for device enrollment). In this policy, add only the applicable platforms with SSO (Android/iOS in the above example) as separate lines in the policy. For each, use Mobile SSO as the authentication method, and Device Compliance (with Workspace ONE UEM). Then create a policy for “any” that denies authentication. You can also customize the error messages in the Advanced Properties for each policy rule. Below are screenshots from my demo (though I only configured iOS, this should still stand for Android)

b. Assign the policy just to the Ping app you created earlier (where this is only used when WS1 Access is considered an IdP in an authentication flow, that is, for “protected” Ping applications)

5. Create authentication policy in Ping

a. This will dictate to Ping to leverage Workspace ONE for authentication

b. In the Ping console, go to Authentication - Policies - Authentication. Then Add Policy. Specify to use an external identity provider, select the Workspace ONE IdP created earlier, and save.

6. Specify applications to use the authentication policy in Ping

a. In this hypothetical scenario, only some sensitive applications are to be protected by this policy to require a compliant enrolled device prior to access to a SaaS application. For those applications, you can edit them to use the authentication policy we created in the above step.

b. In Ping, go to applications - applications - (select the desired application) - select the Policies option, and check the box for the “protected” authentication policy we created in the above step.

7. All that is left now is to validate the workflow for non-enrolled, enrolled, and non-compliant devices