DRC has expressed an interest in supporting automatic de-provisioning of users who leave your organization via the SCIM 2.0 API.
Currently, if you enable SSO, users who leave your organization will no longer be able to access ActivityInfo, but they will still be listed as a user in your database and consume a license unless you manually remove them.
With the SCIM API, as soon as a user is disabled or deleted in your Microsoft Entra ID directory, their access would be automatically revoked from all databases, and the database owner notified. It would also free up a license for another staff member.
Curious if there is interest from other organizations? Other directories? I believe Google Workspace also support SCIM. Here is a RFC document you can share with your IT team:
We use SCIM2 to provision from Azure into SaaS platforms, and we’re planning on using it to provision from SailPoint IdentityIQ (an IAM product) into KeyCloak databases via a KC plug-in (that can act as a SCIM2 client and server).
The benefit for us would not just be for disabling users but also provisioning users, and keeping our account inventory up-to-date (which we currently do using a batch job/script).
So in summary, I like the idea. I’d like to flag up an issue: compatibility between the various SCIM2 implementations isn’t 100%, and so in practice there’s quite a lot of testing with the different implementations. Azure is a bit screwy I’ve heard but has good online compatibility testing; the KC plug-in is superb. No idea about Okta.
One thing I would request is to somehow keep the name of the user associated with the records in the database even after they get deleted from the users list. We have noticed that revoking the licenses of old users also removes them from the records they have previously entered, likely because the user field references the users database directly. As a workaround, we stopped using the user field and started using a reference field that takes the values from a database with the names of all users active and inactive.
@ian.sollars_gmail.co Thanks for the context! I think we’re going to need to have a “dry-run” mode that will allow us to test this with each new identity system so that we don’t end up dropping users because of mal-formed requests. Hopefully over time we can build up a library of byte-for-byte requests from different systems to include in integration tests.