...
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.
...
The identities in each of these systems is 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 heterogenous heterogeneous systems — – plus the interaction, functionality, and benefits that offers — – the SCIM VDS does this via the SCIM protocol.
...
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.
...
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. Well that sounds about right; howeverHowever, beyond the lack of SCIM-compliant SaaS applications, there is a huge problem:
...
Cross-System Password Reset
Access Certification
Compliant Risk Management
Role Mining Analytics
Delegated Identity Administration
End-User Email Notifications
Much more
...