31 lines
1.8 KiB
Markdown
31 lines
1.8 KiB
Markdown
---
|
||
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
|
||
---
|
||
|
||
{{< 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
|
||
<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>
|