diff --git a/content/overview/identity-management.md b/content/overview/identity-management.md index 27f5921..5d22c10 100644 --- a/content/overview/identity-management.md +++ b/content/overview/identity-management.md @@ -1,6 +1,6 @@ --- 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 weight : 1 --- @@ -32,12 +32,21 @@ Where are user’s identity & credentials stored? How to manage & transfer user’s identity ? {{< /card >}} {{< /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. + -### Our environment -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. +### SCIM environement +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 : * **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** diff --git a/content/overview/scenario.md b/content/overview/scenario.md index 8cd49b1..930c6fd 100644 --- a/content/overview/scenario.md +++ b/content/overview/scenario.md @@ -1,6 +1,6 @@ --- -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. +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 --- @@ -8,24 +8,24 @@ weight : 3 ### 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** -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**. +**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**. -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) * 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.** -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 -SCIM compliant **open source Web SSO providers** and, **Applications with SCIM API** for user provisioning. +SCIM compliant **open source Web SSO providers** along with **applications that support SCIM API** for user provisioning could provide a seamless user experience. diff --git a/themes/Indiiie/layouts/index.html b/themes/Indiiie/layouts/index.html index 683852a..1ff4a04 100644 --- a/themes/Indiiie/layouts/index.html +++ b/themes/Indiiie/layouts/index.html @@ -7,7 +7,7 @@ Discover SCIM ↓ -