31 lines
1.7 KiB
Markdown
31 lines
1.7 KiB
Markdown
---
|
||
title: How do 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>
|