WS1 UEM SCIM Adapter

Updates

20.03 – Release Notes and updated deployment instructions


Today is an exciting day. It’s my first experience developing a VMware Fling, and it’s is the GA release of what Joe Rainone and I put hours of laborious love into. Identity is not only our day job, but also an area that we are both very passionate about. Our belief is that this Fling, while unsupported, answers a question that many of our customers ask when designing production Workspace ONE deployments. Take a look, play around, and please provide feedback here!

What is the Fling about?

The SCIM protocol is quickly modeling after what SAML brought to identity management almost 15 years ago: a common way to establish resource identity in a service-to-service architecture. Gone are the days where LDAP and Active Directory are the primary systems of record. This concept is particularly enhanced as EUC platforms like Microsoft Azure, VMware Workspace ONE, and others provide native directory services while maintaining a common identity among themselves and their relying parties. Furthermore, the burden of maintaining ‘connector’-like infrastructure for the sole purpose of identity synchronization not only diminishes the value of cloud-based identity stores, but also fosters dependence on secondary technology that isn’t critical to cloud-first initiatives.

The Workspace ONE UEM SCIM Adapter was created by Joe and I to address this very gap in Workspace ONE: AD/LDAP dependence for identity sourcing. In short, the Fling “provides user and group resource management capabilities to Workspace ONE UEM. The middleware translates the System for Cross-Domain Identity Management, SCIM, to a CRUD REST framework that Workspace ONE UEM can interpret. This capability allows Workspace ONE UEM to synchronize cloud-based identity resources (users/groups/entitlements) without the need for an LDAP endpoint (service to service model).” We’ve finished testing with Azure AD, and are far down the path of enabling Okta Universal Directory as a documented source system.

A brief look at the flow from Azure AD to WS1 UEM using this Fling:

Azure AD User SCIM Provisioning Flow

Deploying on Bitnami

The gory details around prerequisites, functionality, and process map are all included here and in the README contained in the tar file. What isn’t included, and the focus of this post, is an example deployment using real-world architecture. Check out Camille’s post on a directions for deploying on Photon OS, or continue reading for step-by-step guidance to deploy on Bitnami Certified Node.js. Side note, VMware recently announced its acquisition of Bitnami. Interesting point of inflection…

Overview of Deployment Procedure

  1. Deploy and Configure Bitnami Certified Node.js Appliance
  2. Upload and extract Fling tarball
  3. Install and Configure SCIM Adapter
  4. Start Apache and ws1scim services
  5. Enable Azure AD provisioning

As mentioned in the prerequisites, I will assume that you have environmental settings in place, such as a working and properly licensed Azure AD tenant, WS1 UEM 1810+ tenant, and the plumbing in between to enable the Azure AD provisioning functions.

Deploy and Configure Bitnami

Bitnami offers several flavors of this appliance. YMMV depending on choice, but the configuration should remain the same regardless. I’m partial to the AWS EC2 offering and will be using it to document the below. Once your appliance is deployed:

Upload and Extract Fling

1. Download the latest version of the Workspace ONE UEM SCIM Adapter

2. From within your download directory, open an SCP connection and upload to Bitnami:

scp ./ws1_uem_scim_adapter_2003.ga.tar.gz bitnami@scim.virtualprivateer.com:/home/bitnami/

Install and Configure SCIM Adapter

1. Extract the tarball in your Bitnami user’s home directory:

sudo tar -zxvf ./ws1_uem_scim_adapter_2003.ga.tar.gz

2. Install the service and it’s dependencies (include quotes around API key and trailing line break to prevent carriage return):

sudo ~/install.sh --host {uem_api_server} --api-key "{your_customer_og_tenant_code}" --port {port_for_service_to_bind} --serviceurl {your_scim_url_here} --email "{your_admin_email_here}"

For example:

sudo ~/install.sh --host cn000.awmdm.com --api-key "abc123thisisbase64==" --port 9000 --serviceurl scim.example.com --email "noreply@example.com"

After you press ‘Enter’, you should see a series of log lines indicating progress, steps taken, and the result of verification. Lastly, to persist the applet:

3. You can run a quick test from your web browser by going to http://{YOURDOMAIN}/ping. A successful test will promote your connection to https with a valid certificate, and display ‘hello’ in the body.

Enabling Azure AD Provisioning

Time to conjure up the magic. Assuming you have met the prerequisites and successfully deployed the Fling, head over to Azure AD and select your WS1 UEM enterprise application configuration. Then, select ‘Provisioning’.

1. Change the Provisioning Mode from Manual to Automatic:

2. Set the ‘Tenant URL’ to https://{YOURDOMAIN}/scim and the ‘Secret Token’ to base64 encode of your WS1 UEM API admin. Press ‘Test Connection’ to confirm the settings, then press ‘Save’ before moving forward:

3. Expand ‘Mappings’, then select “… Groups to customappsso”:

4. Change the ‘objectId’ AAD Attribute mapping to ‘displayName’, press ‘Save’, then close the ‘Attribute Mapping’ blade:

5. In the ‘Mappings’ section, select “… Users to customappsso”:

6. Select ‘Show Advanced Options’, then select ‘Edit attribute list for customappsso’:

7. At the bottom, input a new attribute with the name “urn:ietf:params:scim:schemas:extension:scimgateway:2.0:User:immutableId” and type “String”. Select ‘Add Attribute’ once completed:

*Note: You can add additional custom attributes that map 1:1 to custom attributes in UEM following the same naming schema, i.e. “urn:ietf:params:scim:schemas:extension:scimgateway:2.0:User:customAttribute2”. Camel case, such as’customAttribute2′, is required. ‘customAttribute1’ is reserved and unavailable for mapping. See Fling documentation for more details.

8. Per the documentation here, map the supported attributes in the schema, press ‘Save’, then close the ‘Attribute Mapping’ blade:

*Note: Take notice of the immutableId mapping to the previous attribute you just created in the schema.

9. Select the ‘Users and groups’ blade, then select ‘Add user’ to entitle users and/or groups to the WS1 UEM environment (recommend starting with small subset for testing):

10. Once you have entitled resources, select the ‘Provisioning’ blade once more, then toggle the ‘Provisioning Status’ option to ‘On’, confirm the ‘Scope’ is set to ‘Sync only assigned users and groups’, then press ‘Save’:

After a few moments (depending on sync size), you will notice Azure AD feedback indicate that objects have been created in the target system:

Confirming the resource residence in Workspace ONE UEM Admin Console (first screenshot showing users, second showing group and membership):

In a deprovision event (account disabled, resource entitlement removed, etc), a ‘softDelete’ is transmitted for user resources which disables the account in Workspace ONE UEM. Groups are hard deleted if they’re removed from the enterprise application in Azure AD.

Lastly, testing indicates that Azure AD runs an incremental sync on the last known watermark every 20 minutes or so. This is subject to change, but has been consistent over the recent past.

The World is Your Oyster

Joe and I sincerely hope you enjoy the functionality this Fling has to offer. We are very interested in your feedback, so please provide us with comments and bug requests as they arise.

Tags: , , , , , ,