Image credits: cottonbro from Pexels
What is SCIM?
Over the last few years, the world has been moving from on-premises to cloud-based environments. In this migration process, identity provisioning becomes a critical factor due to confidentiality concerns and the security of user data. The System for Cross-domain Identity Management (SCIM) specification is designed as an open standard for managing user identity in cloud-based applications and services easier, faster, and cheaper. This specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on the simplicity of development and integration while applying existing authentication, authorization, and privacy models.
According to the rfc7642 specification:
The System for Cross-domain Identity Management (SCIM) specification is designed to manage user identity in cloud-based applications and services in a standardized way to enable interoperability, security, and scalability.
The goal of SCIM is to automate the identity provisioning process, therefore, to reduce the cost of identity management and improve security. The automation process will simplify the user experience. SCIM is all about identity provisioning. So what is identity provisioning? Identity provisioning is creating, maintaining, and deleting user accounts and related identities in one or more systems or applications in response to business processes.
Let’s say that the company ABC uses some cloud applications like Gmail, Salesforce, and some other cloud applications. A new employee Bob joins the company. During the on-boarding Bob process, the HR manager wants to create a new user profile for Bob in the central identity directory and grant access to other services. It is not efficient for admins to enter user information in all those environments. At this point, the provisioning framework comes into the picture. The provisioning framework will tackle the burden of the admins. It will automatically provision the new users to those cloud applications and services.
Traditional way of provisioning
As you can see in the diagram, in the traditional mode of provisioning, each of the services will have its own way of communicating with the provisioning framework resulting in multiple connectors. This is a redundant integration effort for ECS and CSP. Maintaining and supporting these individual connectors will become a nightmare to admins and incur an extra cost. SCIM for identity provisioning was designed to mitigate such scenarios so that everyone agrees on an open protocol or a common way of communicating.
How Does SCIM Work?
The underlying concept of SCIM 2.0 is based on a common user schema, group schema, and an extension model that are exchanged via an HTTP based protocol. It has an object model where a Resource is the common denominator and all the other SCIM objects are derived from it. A resource must have an id, externalId, and meta as attributes. User, Group, and EnterpriseUser extend the common attributes. SCIM is not exclusive to these resources and may be extended to support other resource types.
Object model of SCIM
A SCIM server provides a set of resources, the contents that are allowed are defined by a set of schema URIs and a resource type. A “Resource” is a JSON object containing a “schema” attribute that indicates a list of one or more URIs included in the SCIM schemas. SCIM’s support of schema is attribute-based, where each attribute may have a different type, mutability, cardinality, or returnability. Validation of documents and messages is always performed by an intended receiver, as specified by the SCIM specifications. An attribute at least consists of the attribute name and one simple or complex value, either of which may be multi-valued.
Example for User resource
"userName": "[email protected]",
"displayName": "Babs Jensen",
"value": "[email protected]",
"value": "[email protected]",
"display": "Tour Guides"
SCIM provides a REST API with a rich but simple set of operations for resource manipulation.
The SCIM specifies well known endpoints for managing resources with the above operations. SCIM provides three endpoints; /Serviceproviderconfig, /Resourcetype, and /Schema to discover supported features and specific attribute details.
To further understand the concepts that were discussed above, let’s consider a few scenarios and use cases where the SCIM is engaged.
Triggers: Actions or activities that start SCIM flows
- Create SCIM Identity Resource - Service Onboarding Trigger
- Update SCIM Identity Resource - Service Change Trigger
- Delete SCIM Identity Resource - Service Termination Trigger
- Single Sign-On (SSO) Trigger - Service Access Request
Actors: Operating parties that take part in both sides of the SCIM protocol exchange and help identify the source of a given Trigger
- Cloud Service Provider (CSP): A CSP is an entity operating a given cloud service
- Enterprise Cloud Subscriber (ECS): An ECS represents a middle tier of aggregation for related identity records
- Cloud Service User (CSU): A CSU represents the real cloud service end-user
Modes: The functional intent of a data flow initiated in a SCIM scenario
- Push: Pushing data to an authoritative identity data store
- Pull: Pulling data from an authoritative identity data store
- Migration of the identities
The company ABC has stored identity information of its employees in a cloud service provider CSP_X and they want to move the identities into a cloud provider CSP_Y without changing the format of identity information.
- SSO service
Bob has an account in an application hosted by a cloud service provider CSP_X. CSP_X has federated its user identities with a cloud service provider CSP_Z. When Bob accesses an application hosted in CSP_Z, it relies on Bob’s authentication by CSP_X.
- Provisioning of user accounts for a Community of Interest
Organization ABC provides HR services to a Community of Interest (COI) COI_X. COI_X has offices all over the world and user information is collected through the regional offices. Organization ABC services provide means for provisioning and distributing the employee identity information across all COI_X offices enabling the employees to access applications running on private and public clouds.
- Transfer of attributes to a relying party’s website
Bob has an account in a directory service ABC with one or more attributes. Bob then visits the website of the relying party XYZ and the website requires attributes of the user. Bob selects some attributes and authorizes the transfer of data via authorization protocols (e.g., OAuth, SAML), so selected attributes of the user are transferred from the user’s account in directory service ABC to the website of the relying party XYZ at the time of Bob’s first visit to that site.
- Change notification
Bob has an account in a directory service ABC with one or more attributes. Bob then visits the website of the relying party XYZ and the website requires attributes of the user. The website queries directory service ABC for attributes associated with Bob and related resources. Then Bob may decide to change his name or to terminate the relationship with directory service ABC and directory service ABC will notify these changes to the relying party XYZ.
Even though there are existing standards to describe and exchange user information, many of these standards could be difficult to implement and use. SCIM specifications are designed to make identity management in cloud-based applications and services easier, cheaper, and faster. The SCIM protocol is an application-level protocol for provisioning and managing identity data specified through SCIM schemas.