1.7 KiB
| title | description | color | weight |
|---|---|---|---|
| How we use SCIM | Our focus is around **collaborative tooling**. Thus, information to provision are only email, first name, last name and display name for users and name and membership for group. | blue-2 | 3 |
SCIM Client and Server
While SCIM is a protocol for provisioning and managing identity, there isn’t really a concept of Identity Provider (IdP). In SCIM architecture, there is (only) the Client, making the HTTP calls and the Server receiving them.
Our use of SCIM Our chosen architecture is as follows : a SCIM Client collocated with the Identity Provider will reflect changes by calling all SCIM Server collocated with each application.
What we need is interoperability at 2 levels :
- between the user management UI and the IdP (the database where identity are stored)
- and between the IdP and the applications.
Thus, the IdP is both a SCIM client and server ; client when sending requests to apps and server when receiving requests from management UI.
How it works ?
With SCIM protocol, clients can create, read, update, delete (CRUD) users and groups from a server.
In our scenario when we want to CRUD a user in the Identity Provider, we can therefore use the standard SCIM API to do so.
And, when a resource is modified in the user database of the Identity Provider, the event is propagated to the configured applications. In this case the IdP becomes a client for this application (and this application should be a SCIM Server in this scenario).
In essence
SCIM compliant open source Web SSO providers and, Applications with SCIM API for user provisioning.