scim-docs/content/overview/scenario.md

---
title: How to use SCIM?
description : An **opinion on using SCIM** to provide information such as mail, first name, last name, group... accross different application **with an Identity Provider**.
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)** 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
<mark>SCIM compliant **open source Web SSO providers** along with **applications that support SCIM API** for user provisioning could provide a seamless user experience.</mark>