description : 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.
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).
