redaction corrections (changing "we"/"us"/"our" for a more neutral explanation)
This commit is contained in:
parent
74bd2bdc09
commit
c05dbd1457
5 changed files with 28 additions and 18 deletions
|
@ -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 user’s identity & credentials stored?
|
||||||
How to manage & transfer user’s identity ?
|
How to manage & transfer user’s 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**
|
||||||
|
|
|
@ -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 **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**.
|
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**.
|
||||||
|
|
||||||
**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>
|
||||||
|
|
|
@ -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 }}
|
||||||
|
|
|
@ -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>
|
||||||
|
|
|
@ -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%;
|
||||||
}
|
}
|
||||||
|
|
Loading…
Reference in a new issue