redaction corrections (changing "we"/"us"/"our" for a more neutral explanation)
All checks were successful
/ build (push) Successful in 22s
/ deploy (push) Successful in 4s

This commit is contained in:
timothe.jeanne 2024-10-08 17:02:24 +02:00
parent 74bd2bdc09
commit c05dbd1457
5 changed files with 28 additions and 18 deletions

View file

@ -1,6 +1,6 @@
--- ---
title: Identity Management title: Identity Management
description : "What we speak about and in **which environment**. We must agree on some **different problematics** that exists to better understand why we use SCIM." description : A **quick overview** of some different issues that exist when **discussing identity management**, and in which environments using SCIM could be relevant.
color : yellow color : yellow
weight : 1 weight : 1
--- ---
@ -32,12 +32,21 @@ Where are users identity & credentials stored?
How to manage & transfer users identity ? How to manage & transfer users identity ?
{{< /card >}} {{< /card >}}
{{< /grid >}} {{< /grid >}}
Among all these identity management concepts, SCIM is a matter of provisioning ; it concerns how information linked to an identity is transferred between different apps.
<img alt="illustration of losing data" src="media/illus-loose-data.svg" class="float-right w-60"> <img alt="illustration of losing data" src="media/illus-loose-data.svg" class="float-right w-60">
### Our environment ### SCIM environement
Our digital work environment is composed of **many applications** and web services. We want a **seamless user experience** for our free software based collaboration platform. With a **Single Sign-on (SSO)** system users get a unified login and logout experience but there is a catch. Because SCIM tackle the question of provisioning, one of best the identity management environments where SCIM is relevant is an environment composed of many apps or services that are **not well integrated natively** and are used by many users.
### Our problem To better understand, let's consider the use case of a hosting provider that develops a collaboration platform based on different free software.
The digital work environment is then composed of **many applications and web services** used by **different users.** These users want **a seamless user experience** across the different apps.
With a **Single Sign-on (SSO)** system, users get a unified login and logout experience but there is a catch.
### The problem
Traditional SSO protocols like OpenID Connect do **not support syncing user profiles across applications.** That's means : Traditional SSO protocols like OpenID Connect do **not support syncing user profiles across applications.** That's means :
* **users are not created by default in all apps** (only after they have logged in at least once) * **users are not created by default in all apps** (only after they have logged in at least once)
* **no mechanisms to propagate the deletion of users** * **no mechanisms to propagate the deletion of users**

View file

@ -1,6 +1,6 @@
--- ---
title: How do we use SCIM ? title: How to 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. 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 color : blue-2
weight : 3 weight : 3
--- ---
@ -8,24 +8,24 @@ weight : 3
<img alt="Scim diagram" src="media/scim-diagram-1.svg" class="float-right"> <img alt="Scim diagram" src="media/scim-diagram-1.svg" class="float-right">
### SCIM Client and Server ### SCIM Client and Server
While SCIM is a protocol for provisioning and managing identity, there **isnt really a concept of Identity Provider (IdP)**. In SCIM architecture, there is (only) **the Client, making the HTTP calls and the Server receiving them**. While SCIM is a protocol for provisioning and managing identity, there **isnt 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**.
**Our use of SCIM** **An opinion on SCIM use**
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**. 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**.
What we need is interoperability at 2 levels : 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) * **between the user management UI and the IdP** (the database where identity are stored)
* and **between the IdP and the applications**. * 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. 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 it works ? ### How does it work ?
With SCIM protocol, **clients can create, read, update, delete (CRUD) users and groups from a server.** 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. 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 this application (and this application should be a SCIM Server in this scenario). 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 #### In essence
<mark>SCIM compliant **open source Web SSO providers** and, **Applications with SCIM API** for user provisioning.</mark> <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>

View file

@ -7,7 +7,7 @@
<a class="btn lv1" href="#content">Discover SCIM ↓</a> <a class="btn lv1" href="#content">Discover SCIM ↓</a>
<!--<img class="img-background" src="media/global.png"></img>--> <!--<img class="img-background" src="media/global.png"></img>-->
</section> </section>
<div id="content"> <div id="content" class="w-100">
{{ range sort (where .Site.RegularPages "Section" "overview") ".Params.weight" }} {{ range sort (where .Site.RegularPages "Section" "overview") ".Params.weight" }}
{{ partial "home-section-render.html" . }} {{ partial "home-section-render.html" . }}
{{ end }} {{ end }}

View file

@ -15,7 +15,7 @@
</ul> </ul>
</div> </div>
<div> <div>
<a class="btn lv2" target="_blank" href="https://simplecloud.info">See the official spec</a> <a class="btn lv2" target="_blank" href="https://simplecloud.info">Other resources</a>
</div> </div>
</nav> </nav>
</div> </div>

View file

@ -688,7 +688,7 @@ table svg:nth-child(2){
td em { td em {
display: none; display: none;
} }
.content, footer, header>div{ .content, footer{
width: 85%; width: 85%;
} }
header>div{ header>div{
@ -722,6 +722,7 @@ table svg:nth-child(2){
.main-first svg{ .main-first svg{
margin-top: 4em; margin-top: 4em;
} }
.content, footer{ .content, footer{
width: 87%; width: 87%;
} }