...
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 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.
...
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.
...
Benefits of Using the EmpowerID SCIM VDS for Azure User Provisioning
...
To have full control, organizations need to inject their business logic into the process.
...
...
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.
| Insert excerpt | ||||||
|---|---|---|---|---|---|---|
|
...