Identity Management
What we speak about and in which environment. We must agree on some different problematics that exists to better understand why we use SCIM.
Who is this user ? Is this user allowed to access this resource ? Where are user’s identity & credentials stored? How to manage & transfer user’s identity ?Authentication
Authorization
Storage
Provisioning
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.
Our 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
- So its not GDPR compliant (by default)
In essence
Current existing protocols are difficult to implement or/and to use or are custom for specific use case then non-standardized.
The solution, SCIM
SCIM, for System for Cross-domain Identity Management are specifications designed to make managing user identities in cloud-based applications and services easier.
Quick overview
The SCIM protocol is an application-level protocol for provisioning and managing identity data specified through SCIM schemas. Its intent is to reduce the cost and complexity of user management operations.
- A common existing user schema and deployments
- Extension models
- Placing specific emphasis on simplicity of development and integration
- Applying existing models (authentication, authorization, and privacy)
- Binding documents to provide patterns for exchanging this schema using standard protocols
- Easily improve GDPR compliance
- Consolidate the user experience across multiple FOSS applications as one platform
Resource based
In SCIM 2.0 a Resource is the common denominator and all SCIM objects are derived from it.
Rest API
An api to manipulate resources, from patching a specific attribute to doing massive bulk updates.
Ends points
SCIM provides three end points to simplify interoperability and discover features and details.
In essence
Make it fast, cheap, and easy to move users in to, out of, and around the cloud.
How do we use SCIM ?
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.
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
SCIM compliant open source Web SSO providers and, Applications with SCIM API for user provisioning.
Why is SCIM better ?
Differences between several centralized user management protocols in a world of web application hosting that show SCIM is an upgrade.
Others management protocols
With this LDAP approach everything is centralized (except authorization).
Everything speaks the LDAP protocol langage. Identities are stored in an LDAP directory, which is provisioned via LDAP protocol. Authentication is done by the application that asks the user’s credentials and validates them against the directory via LDAP protocol.
This architecture tackles the two main drawbacks of the only LDAP approach : the missing single sign-on and the security vulnerability. Authentication is delegated to other web protocols (like OAuth, OIDC or SAML). This way, the user logs in only once to the identity provider.
On modern web infrastructure, LDAP started to be abandoned because loose provisioning can also be done via SSO protocols.
SCIM solve the remaining problems via a simple standard web api. This infrastructure is event driven, a provisioning action on the IdP is quickly passed on all applications.
| LDAP | LDAP & SSO | SSO | SSO & SCIM | |
|---|---|---|---|---|
| Easy to implement |
Mature but old and difficult |
Mature but old and difficult |
Simple and web native, but non-standard IdP |
Cli or UI could be used on IdP or on apps |
| Many implementations |
Not a lot of implementations yet |
|||
| Single sign-on |
User must sign-on each application |
|||
| No trust issues |
Expose user’s credentials to each application |
??????? |
Zero trust in applications |
Zero trust in applications |
| Scalable provisioning |
By diffing, each app reads all and compares it |
By diffing, each app reads all and compares it |
No diffing, modern storage, SQL database can be used |
Real time atomic provisioning |
| Scalable provisioning |
Only when apps trigger it or when the user logs in |
Only when apps trigger it or when the user logs in |
No way to remove a user from the application |
|
| GDPR Compliant |