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

What is a Virtual Directory?

Virtual directory servers allow you to gather the information that is contained in heterogeneous sources and present it to users as a consolidated view that appears to be coming from one central repository. Virtual directories provide an abstraction layer between disparate data stores, such as:

payroll systems
HR systems
Active Directory
others

Virtual directories allow information consumers to interact with the information contained in those systems without actually connecting to them. The virtual directory receives queries, retrieves the appropriate data from each back-end system, and sends it to the user in the form of a virtualized view. For example, many organizations may have more than one repository for holding user information.

An HR system may hold one set of attributes
Active Directory may hold another
Yet another application may hold more

The identities in each of these systems are only a "partial identity." To gain a fuller representation of those identities, you need to access each system separately. Virtual directories make it possible to pool the attributes from each of those systems for a more complete user profile. In this way, virtual directories act as an Identity Warehouse, containing information from multiple authoritative sources that can be aggregated in response to queries made against its tree structure, similar to how views can be used to consolidate database tables. Information consumers can avoid querying multiple systems, combing through attributes until they have enough to create a composite.

In the same manner that a VDS provides you with a single, simulated view of your heterogeneous systems – plus the interaction, functionality, and benefits that offers – the SCIM VDS does this via the SCIM protocol.

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 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 calls and directs it 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

Create an API Management Service

Deploy the SCIM Microservice