Overview of SCIM VDS for Azure Identity Management

What is SCIM?

Created in 2011 as an open standard, lightweight provisioning protocol for the “Cloud age,” SCIM provides a uniform way for applications to communicate identity information to each other. Leveraging API, REST, and JSON, SCIM provisions user data in a consistent way that can be stored and accessed across applications. Based on frameworks that are already shared with many SaaS identity management systems, SCIM’s underlying principles are twofold:

To make user data more secure
To simplify and automate the user identity lifecycle management process

Why SCIM VDS?

Simply put, in today’s “work from anywhere” model, cloud-based identity management solutions are quickly becoming the norm. Nowhere is this more evident than with Microsoft’s shift away from on-premise Active Directory federating with Office 365 to Azure AD as the primary identity. De-emphasizing and even eliminating ADFS and federation are bold Cloud First moves by Microsoft and it is the future. Microsoft makes this even more apparent with its integration of the SCIM protocol into Azure. SCIM was created as a powerful means of standardizing, simplifying, and automating identity management of users, groups, and devices across cloud-based applications and services and Microsoft is betting big on it. The Azure AD Provisioning Service uses SCIM to provision users to other systems by connecting to the SCIM user management API endpoint provided by the application vendor. The limitation here is that SCIM has yet to become widely adopted and many applications simply do not support it. So, if you have custom applications with repositories of identity information or use an on-premise or cloud application like SAP S/4 HANA or SAP Ariba, you are not going to be able to integrate those systems with the Azure Azure AD Provisioning Service unless you or the vendor builds a SCIM interface for each. This is no small task because while the protocol is simple, building the interface is not. This is where the EmpowerID SCIM VDS comes into the picture. If you have non-SCIM compliant applications registered in EmpowerID, you can use the SCIM VDS to “make” your non-SCIM applications SCIM compliant. There is no need to wait for vendors or have developers in your organization put in the time and effort needed to build custom SCIM interfaces. The EmpowerID SCIM VDS takes care of everything for you.

How does the EmpowerID SCIM VDS work?

The SCIM Virtual Directory is a microservice and a SCIM server created by EmpowerID that can be deployed as an App Service in Azure tenants. This allows the SCIM VDS to be the go-between for Azure and any enterprise applications registered in EmpowerID. Provisioning calls are made from Azure AD to the EmpowerID SCIM VDS, which then directs the call to each system in EmpowerID for which Azure provisioning is configured.

The question arises as to how EmpowerID knows what systems to update. The answer to the question is the Tenant URL you specify for the application when setting up provisioning in Azure. This URL is a concatenation of the SCIM VDS app service URL and the name of the application account store in EmpowerID. The below image depicts this. In the image, there are three enterprise applications integrated with EmpowerID configured for Azure provisioning: SAP S/4 HANA, RACF, and SAP Ariba. The SCIM VDS will direct provisioning calls to each of those applications if the URL includes the application. Thus in the image, provisioning is directed to the SAPS4HANA application registered in EmpowerID.

Figure 1: EmpowerID SCIM VDS intercepts Azure provisioning call and directs them to the appropriate system

Benefits of Using the EmpowerID SCIM VDS for Azure User Provisioning

Fills in Azure AD Provisioning Gaps

Azure is here to stay and so is the shift away from on-premise user directories like Active Directory to Azure AD. Microsoft has invested heavily in the cloud and part of the investment includes elevating Azure AD as the primary identity and AD on-premise secondary. If you haven’t yet adopted this approach and begun the transition toward the cloud, you eventually will. There are simply too many reasons not to do so. Microsoft’s aim is to make Azure AD the central point for authentication, conditional access, and MFA. They want you to use Azure AD for all your identity-aware applications. The idea is that you do identity in Azure and Azure propagates that to your other systems. So, for example, if you provision new users in an HR system, those users should be provisioned in Azure AD and then pushed from Azure AD to one or more SaaS applications. However, beyond the lack of SCIM-compliant SaaS applications, there is a huge problem:

The process is blind to your business logic. Users are provisioned and de-provisioned as may be the case, and that is that. There currently is no way to interrupt the process to do other things.

EmpowerID changes that. When added to Azure, EmpowerID gives you the following abilities:

Cross-System Password Reset
Access Certification
Compliant Risk Management
Role Mining Analytics
Delegated Identity Administration
End-User Email Notifications
Much more

Provides Workflow-Driven Directory Services

Traditional SCIM connectors simply “fire and forget.” They pass commands from one system to another and leave it at that. There is no middle layer of logic involved. In other words, they are more of a SCIM gateway. The EmpowerID SCIM VDS takes another approach. Not only does it pass commands from one system to another, but it evaluates your business processes while doing so. We call this approach “everything is a workflow” and it is central to the EmpowerID paradigm.

To have full control, organizations need to inject their business logic into the process.

Figure 2: EmpowerID SCIM VDS versus traditional “fire and forget” SCIM connectors

The above image depicts the difference between the two approaches. In the first flow, Azure AD Provisioning Service sends commands to the EmpowerID SCIM VDS. EmpowerID then invokes the workflow appropriate to the command where business processes can be executed before sending those commands downstream to a connected system. In the second or lower flow, Azure sends the same commands to a directly connected system and they simply happen in that system. There is no control over the transactions. With EmpowerID standing in the middle, the entire process can be evaluated and interrupted if need be.

Next Steps

https://dotnetworkflow.jira.com/wiki/spaces/EAGV22/pages/2809058223

https://dotnetworkflow.jira.com/wiki/spaces/EAGV22/pages/2809058338