---
title: How we use SCIM
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.
color : blue-2
weight : 3
---
 
<img alt="Scim diagram" src="media/scim-diagram-1.svg" class="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)**. 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
<mark>SCIM compliant **open source Web SSO providers** and, **Applications with SCIM API** for user provisioning.</mark>