API-based User Lifecycle and SCIM

February 22, 2022

User lifecycle in a cloud world

Welcome back Devs, today we have a look at using REST APIs for user management in a multi-cloud. It has always been a challenge to keep user identities consistent across different data stores, be it different departments like HR and IT, or different functions like applications or directories. Even using identity federation and single sign-on, it is nearly always required to create user objects outside Identity and Access Management (IAM) systems so that applications can keep all relevant user attributes in local repositories. This is even more relevant for SaaS applications that are outside the customer’s security domain and still need to be considered for On and Off-boarding during the user lifecycle.

After some less successful XML-based framework, development of the System for Cross-Domain Identity Management (SCIM) started in 2011 with the goal of creating an extensible definition and modern protocol, based on REST and JSON objects to run CRUD (Create ,Read, Update, Delete) operations on user and group resources. SCIM 1.1 was released in 2012 and updated in 2015 as SCIM 2.0 (RFC 7642, 7643, 7644) under ITETF. You can learn more about SCIM at www.simplecloud.info.


SCIM works and is secured like other REST-based APIs, so you don’t need to use connectors or expose your LDAP directory. And other than techniques like Just In Time (JIT) which uses the SAML assertion to provision user attributes, it can update or delete a user and group objects without waiting for an authentication to happen.

At the time of this writing, Workspace ONE Access supports SCIM 1.1 for its user management. Workspace ONE UEM uses its own Rest API for CRUD user operations without exposing a user and group schema. Soon that will change, and they will incorporate SCIM 2.0. The first step in that direction will be the Workspace ONE Broker for EUC that will allow provisioning of users and groups from cloud directories like Azure AD into Workspace ONE UEM and Access using SCIM 2.0 which is most widely adopted nowadays.

But even today, you can already leverage the SCIM 1.1 protocol to do API operations for your user lifecycle. With Okta, we already have an existing integration to push users and groups from the Okta Identity Cloud into Access, and from there to UEM.


Graphical user interface</p>
<p>Description automatically generated

For more information, see Okta integration documentation.

There are also examples like the Rollcall SCIM Proxy middleware to bridge the gap between SCIM 2.0 source and SCIM 1.1 on the Access side.

Graphical user interface, diagram, Teams</p>
<p>Description automatically generated

Developer Resources

If you are interested in integrating your own source of identity with Access using the existing SCIM 1.1. endpoint, you can use the documentation on GitHub and the API reference on developer.vmware.com to learn how to authenticate and perform CRUD operations against Access.

Leveraging SCIM in Access now

One immediate benefit for administrators of Access is that knowing about the Access API and SCIM can get you around a shortcoming of the Access Workspace ONE Access administration interface. You can add and sync all the attributes you need in Access.

Graphical user interface, application</p>
<p>Description automatically generated

But you can only see a limited number of attributes in the GUI when you check synced users.

Graphical user interface, application</p>
<p>Description automatically generated

This makes it difficult to check on attributes missing or not updated, that might be used in downstream applications and lead to errors or missing roles for the user.

With what you should know after reading Getting Started with Workspace ONE Access APIs and Introduction to Using Postman, you are able to create a quick search to get all attributes defined in the SCIM schema, be it just a specific attribute or all attributes.

<p>Description automatically generated

Figure 6: Search query with filter for a user and a specific attribute (Id)

<p>Description automatically generated

Figure 7: Search query with filter for a user and all attributes, even tenant extension attributes

If you don’t want to start Postman, you can use the browser to get the user Id and check the user SCIM endpoint. Steve D’Sa wrote a nice little blog about it back in the days, check out the following links for more info. How do I see all the WS1 Access User Attributes? and Using Postman to Manage Workspace ONE Identities

Wrap up

This should give you an idea of which direction user lifecycle will take in a REST API-driven world. With Access, you can already do a lot of things using SCIM protocol. And with the upgrade to SCIM 2.0 and the introduction of Workspace ONE Broker, VMware will be well prepared for this new paradigm.

What’s Next

Be sure to subscribe to the Digital Workspace Tech Zone Blog RSS or check back daily to see what we release. By the end of this month, we hope that you are comfortable leveraging code samples, VMware Flings, scripting/coding, and leveraging the EUC APIs to automate your workspace!

You can also follow us on Twitter @EUCTechZone to stay updated on the latest EUC content!


Make sure to check out the other blog posts in our 28-day series:

Filter Tags

Horizon Workspace ONE Horizon Workspace ONE Access Workspace ONE Intelligence Workspace ONE UEM Blog Technical Overview Intermediate Windows 10 Optimize