I don’t even know where to start here!
This project has been one of the most frustrating but educational things I have done in a long time. For a long time I continually get asked how we can use Azure Active Directory natively in Workspace ONE without needing an On-Prem AD and/or LDAP via the Connectors.
Originally I thought it was mostly that the VMware developers just hadn’t prioritised getting this in the Access Environment and it was something that Microsoft just didn’t allow, but after learning Node.js and Angular and taking on this task I realised there was a lot more to it.
So as I just mentioned, I had to learn NodeJS. And then I needed a frontend, so I learned Angular. And then I had to continually troubleshoot niggling issues in provisioning from Azure into Rollcall, so I had to learn the SCIM v1.1 and SCIM 2.0 differences inside out. Then, I didn’t want to do a half baked job of making it into something usable so I learned how to create a docker container from a file and implement a proper reverse proxy with NGINX.
I knew bits and pieces of these, and honestly I am still very much a beginner on this technologies and languages (please don’t be too harsh on my code). I was able to get a good head start from an existing mature project on Github called SCIMGateway, but once I worked out what I needed to do to get the right outcome for my project, I ended up modifying that code quite a lot.
At a high level, Azure AD has the ability to do outbound SCIM 2.0 provisioning from ‘Enterprise Applications’ that are adding into the Azure AD Admin Portal. Workspace ONE Access has the ability to handle inbound SCIM requests and create, read, update and delete Users and Groups. With those bits of information, that all seems pretty straight forward. Which is what I thought too. What I found however was that Azure AD only supports SCIM 2.0 and Access only supports SCIM 1.1. Outside of that, Azure is VERY specific about the JSON responses it receives to its API requests and Access has a VERY specific structure of its expected API calls to create objects. And if that wasn’t enough, Azure AD has a hard set won’t budge no workaround limit of 1kb for all configuration relating to Provisioning in the Enterprise Application. Yep, 1kb. That includes the URL, schema, and most annoyingly this also included the JWT Bearer token that you need to enter to communicate with your backend SCIM Endpoint. I found this last part out after pulling the little hair I have left out through a obscure error message. Unfortunately, Access also doesn’t have a way of specifying the length of its returned Bearer tokens either.
So anyway after about 3 months we have Rollcall.
Project Rollcall consists of two Components:
Access Proxy: which is a Node.JS and Express application that listens for SCIM API requests/actions from Azure Active Directory and your Custom Enterprise Application with Provisioning Enabled.
Admin UI: which is the configuration and administrative interface built on Angular and VMware’s Open Source Clarity UI framework. It also serves as an interface for additional Workspace ONE Access Tools required to complete Provisioning rather than having to use Postman.
All the code is up on Github, along with instructions on how to build it in a Docker container, configure Azure AD and deploy Rollcall to enable SCIM creation of Users and Groups into Access.
Leave a Reply