1.8 KiB
| title | description | color | weight |
|---|---|---|---|
| How to use SCIM? | An **opinion on using SCIM** to provide information such as mail, first name, last name, group... accross different application **with an Identity Provider**. | blue-2 | 3 |
{{< imgproc "scim-diagram.png" "Scim diagram" "float-right">}}
SCIM Client and Server
While SCIM is a protocol for provisioning and managing identity, there isn’t really a concept of Identity Provider (IdP) within its architecture. Instead, SCIM architecture consists (only) of a Client which makes HTTP calls, and a Server, which receives them.
An opinion on SCIM use A possible architecture could be as follows : a SCIM Client collocated with the Identity Provider reflects changes by calling all SCIM Servers collocated with each application.
With this architecture, there is a need for 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 acts as both a SCIM client and server ; as a client when sending requests to apps and as a server when receiving requests from management UI.
How does it work ?
With SCIM protocol, clients can create, read, update, delete (CRUD) users and groups from a server.
In this scenario the standard SCIM API is used each time an user should be CRUDed in the Identity Provider.
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 these applications (which act as a SCIM Server in this scenario).
In essence
SCIM compliant open source Web SSO providers along with applications that support SCIM API for user provisioning could provide a seamless user experience.