User lifecycle is very important, but can be quite the challenge. Big projects have a big cost to implement or upgrade. Or you may need to change tool completely, because it wasn’t that future proof in the new world of services.
Grab your favorite beverage (coffee) and lets have a look at the new API from Entra ID coming to rescue us from data leaks due to unstructured and manual identity and access management.
First, why is user lifecycling important?
In order to remain secure we need continued control over user and their access. People get hired, move on and change positions inside companies all the time. Enterprise customers need to automate this process, because it is very labor heavy and we often make mistakes/shortcuts. Smaller customers might handle this manually, but it will not scale into the future growth.
When people come, there should be created a user with the right access, in order to have them work efficiently from day 1.
When people leave, usually because a contract was terminated, the user with data should be handled according to regulations, and access should be revoked from their last day.
When people change positions, we should change their access according to the new position. The new position might need different access and should no longer have access to previous positions privileges.
News! Entra ID Provisioning API (Public preview)
This right here, can solve a lot of problems customers meet when dealing with growth and security surrounding users or their digital identities. Especially in term of user lifecycle and access management.
Entra ID recently released an API which gives anyone access to handle lifecycle of users in Entra ID.
You can build your own solution and it will make it much easier for third party vendors to integrate their lifecycle management into Entra ID. Some third party vendors also has option to code against external sources, which we can do against this API.
Hybrid identities
We will also have support for hybrid identities, where the agent behind the API will manage users in Active Directory, then synchronized to Entra ID using Cloud Sync.
SCIM Schema
Yes, SCIM schema (Supply Chain Integrity Model), you read that right. It might have been forgotten, because the Enterprise Application SCIM provisioning support didn’t really hit the right spots in order to grow. I did like the idea, but third party apps haven’t really been onboarding this train.
The Entra ID API for provisioning is also using the SCIM schema, and that is what the agent behind the API is reading from your API calls.
Test it yourself
Microsoft has published a sustentive guide to configure and test the API Provisioning using either cURL, Postman or Graph Explorer.
Inbound API-driven provisioning concept (public preview)
Configure API-driven provisioning app (enterprise application)
Grant access to the inbound provisioning API
Test-run using cURL
Test-run using Postman
Test-run using Graph Explorer
It isn’t done in an minute and you need different set of roles in Entra ID in order to finish your configuration. So make sure you have the necessary roles, perhaps a test-tenant as well.
Provisioning user-data from Entra ID
User life cycle and access management has been around for decades, and if you used to this with Microsoft, you are probably familiar with Microsoft Identity Management tool (today MIM, used to be FIM).
Entra ID haven’t had the same outbound features as MIM, so it haven’t been able to successfully take over the responsibility held by MIM. We could work around using PowerShell scripts and whatever language the external application is talking.
But I would like to introduce the ECMA Connector Host, which is an Entra ID feature allowing us to run MIM connectors from Entra ID without having MIM. Maybe your application is running a SQL database, and you need to populate data into your SQL database/application. The ECMA Connector Host can do that, like we used to do with MIM. For in depth guide to do so, please read my friends blogpost here.
Provisioning with claims (alternative)
User-data can also be provisioned using information in the token, should your application be federated with Entra ID.
SAML federation has been the most common and hence have been the most documented option out here.
OpenID/OpenID Connect is a newer option, ment to supersed SAML, and when you can, should be your preferred option. OpenID-Connect has the ability to separate information into an additional token, which is transferred if your ID token has been approved.
In bought of them we configure information known as claims, where we chose which attributes from Entra ID we include in the token.
By doing so, the application can read unique information about each user and store it in its own database. If information are changed, it should be able to update the users data next time they logon.
The downside to this, is the application doesn’t know you until your first successful sign-in. So in case you need to sort users based on information from Entra ID it needs to be automated based on claims. Or else the user will have limited access in the application after first sign-in, until the applications administrators assign your permission.r
