System for Cross-domain Identity Management: Definitions, Overview, Concepts, and Requirements

SCIM Components and Architecture SCIM architecture is a client-server model centered on a normative concept of a "resource". Resources have types (such as a user or a group) and each unique instance of a resource type is represented by a JSON object, actively accessed via a standardized REST API. Each resource object can be managed individually or managed in bulk using actions that by default are specified in (HTTP GET, PUT, POST etc), but that may expand to concepts in extension documents, for example security event tokens (SETs). This model therefore enables organizations to represent information about user populations and the groups that these user populations are part of using the core specifications and to extend to other important resources using extension drafts in the same family with the high level concepts of performing SCIM actions on resource objects. SCIM actions result in resource object and associated data "moving" between the client and server, as clients actively push and pull information that reflects change over time. This communication of data enables systems within domains and across domains to operate on the freshest possible version of object state.

| Client | | /Users | | | | /Groups | | | +---------+ +--------+ ]]> The specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models.
The intent of the SCIM specification is to reduce the cost and complexity of resource management operations by providing a common schemas and extension model, as well as binding documents to provide patterns for exchanging this schema using standard protocols. In essence, make it fast, cheap, and easy to move resources in to, out of, and around the applications.
The SCIM scenarios are overviews of user stories designed to help clarify the intended scope of the SCIM effort.

Evolution and new Challenges As the protocol has been adopt since its introduction in 2012, most of the IDMs and applications started to adopted it, mainly in the replacement of old protocols like LDAPv3. With the implementation the market started to reach more complex topologies, no longer the simple Client Server where there were only two SCIM entities. We start to see many different SCIM entities with different roles and doing its own manipulation of the object (RO) and its attributes (RA). The maturity of the protocol also brought some challenges, that we don't plan to enumeratee all of them, but give a couple of examples.

Reconciliation For some reason, the RO and its RA’s that was push by the Client was change in the Server (by some mechanism that was outside the SCIM agreement), which means that until the RO or one of its RA’s changes in the Client, there will be no “fix” to the RO and its RA that are in the Server.

HR Applications This type of SCIM element doesn’t do any management to the RO and RA information, but it is the creator for RO and RA, most of the times have the RA that are generic to all applications (like firstname, lastname, national ID, office address, home address, etc.), most of the times this elements will not know RA like email, telephone number, etc. This RO and Ra needs to be available in the IdMs, for them to provide it to all the SCIM subscribers application.

Extra RA for RO Some SCIM application that are typically SCIM Servers, are the creators and updaters of specific RA, for example an email server that will be a SCIM server should create the email RA for all the RO, but should only consume the other RA like firstname, lastname, etc.

Implementation Concepts To understand the use cases we need to understand 4 different concepts of the protocol, that will describe underlying protocol, the different orchestrators roles, how we start the SCIM interaction and what methods we have to execute the actions.

Data Model SCIM defines two types of data entities: resources and attributes.

Resource Object (RO) A JSON object representing a user, group (or extension object) to be manipulated through the SCIM protocol. The Resource Object contains attributes defined by schemas such as those defined in and can be acted on via the endpoints and parameters defined in .

Resource Attribute (RA) A named element of a Resource Object. Attributes are defined in section 2 of and include characteristics like cardinality (single or multiple values), data types (string, boolean, binary etc) and characteristics (required, unique etc).

HTTP Client-Server Roles HTTP client and server roles are defined in and . Any SCIM interaction requires one participant to be a SCIM server and the other to be a SCIM client.

SCIM Server (also known as a SCIM Service Provider) An HTTP web application that provides identity information via the SCIM protocol.
A SCIM Server is a RESTful API endpoint offering access to a data model that can be used to push or pull data between two parties. SCIM servers have additional responsibilities such as API Security, managing client identifiers & keys as well as performance management such as API throttling.

SCIM Client A website or application that uses the SCIM protocol to manage identity data maintained by the service provider. The client initiates SCIM HTTP requests to a target SCIM Server. A SCIM Client is active software that can push or pull data between two parties.

Orchestrator Roles Orchestrators are the operating parties that take part in a SCIM protocol exchange and ensure data is moving in the correct flows. An entity can have one or more orchestrators roles, depending on the overall provisioning architecture.

Resource Creator (RC) An entity responsible for creating the Resource Object (RO). Typically we can see this role in HR or resource management applications that are responsible for creating resources and some of its attributes.

Resource Updater (RU) An entity responsible for updating specific attributes of a Resource Object (RO) or the RO itself. Typically, this role is used in conjunction with other SCIM roles that allow this SCIM entity to manage a specific Resource Attribute (RA).

Resource Manager (RM) An entity that aggregates or transforms resource objects from resource creators/updaters (RC/RU) and make them available for resource subscribers (RS) using multiple SCIM interactions, an example of this role could be an Identity-as-a-Service (IDaaS) cloud platform.

Resource Subscriber (RS) An entity that consumes information in resource objects (RO) and typically don't create new objects or attributes. An example of entities that play this role include SaaS applications relying on an IDaaS cloud platform.

External Resource Creator (ERC) An entity that has information about resources and its attributes, but does not participate in SCIM flows, examples include databases or internally-facing applications.

Triggers Triggers are actions or activities that may cause a SCIM action to occur. Triggers can occur as a result of business processes like a corporate hiring event, but can also be scheduled events such as a unix bash script running as a chron job, or can be just-in-time events such as SAML assertion arriving at a federated relying party that identifies a not-seen-before user. Triggers can also be standardized events, such as those in the OpenID Shared Signals Framework. Triggers used to allow CRUD (Create, Read, Update, Delete) using SCIM Actions or Operations as it is designed to capture a class of use case that makes sense to the actor requesting it rather than to describe a protocol operation.

Periodic Intervals A periodic interval trigger is a configured-in-advance agreement where a SCIM client performs an action at a specific time. This trigger is often recurring, and in that case the combination of trigger and action together may be referred to as "polling" the SCIM server. An example of a periodic interval trigger could be a UNIX chron job calling a script.

Events Event triggers are activities, contexts or notifications that could happen at any time. A SCIM client may be configured to perform a given SCIM action in response to a specific event occuring such as a specific entry written into an audit log, a signal of a corporate workflow completion, or a device management platform notification. A SCIM action could also be triggered by a Security Event Token (SET) as described in or a SCIM event corresponding to ; for example an application acting as a resource subscriber and SCIM client could receive a SCIM event denoting creation of a new user object, triggering a SCIM action to fetch all the attributes for that user.

Application Triggers Application triggers occur when administrative or end-user interfaces are manipulated. An example of an application trigger might be a user modifying their profile information, resulting in a SCIM client performing an HTTP POST to update the user's resource object at the SCIM server.

SSO (Single Sign-on) Single Sign-on triggers occur when a user authenticates via federated protocols such as SAML 2.0 or OpenID Connect. If a federated assertion arrives for a user who has not yet been provisioned into the destination application, the application may be triggered to perform just-in-time (JIT) provisioning. This trigger occurs in scenarios where a Single Sign-On flow happens, but not all the resource attributes for the user object are passed in the federated assertion, resulting in a SCIM action to push or pull remaining needed attributes.

| | | (typically | | (typically an | | an IdM) | (2) | SaaS | | | <-------------------------------> | Application) | | | | | | RC/RU/RM | | RS | | | | | +---------------+ +---------------+ Figure 2: SCIM Flow and Entities map ]]> SSO trigger that creates the user and might create some RA (Resource Attributes) of a RO (Resource Object) SCIM actions that will complement the attributes created before with an SSO JIT with additional RA (Resource Attributes) of the RO (Resource Objects) created before.
This use case combines the SCIM protocol with other protocols used for Single Sign-On, specially in the use case of JIT (Just in time Provision), specially useful with protocols like SAML that is limit by the number of characters in the URL.

SCIM Actions The SCIM protocol defines interactions between two standardized parties that conform to HTTP RESTful conventions. The protocol enables CRUD operations by corresponding those activities to HTTP verbs such as POST, PUT, GET, DELETE etc. The protocol itself doesn't assume a direction of data flow, and use cases discussed in section 4 are created using the orchestrator roles and an SCIM entity can have multiple roles, depending on the objective of the use case that we are describing.

Client active Push A SCIM client uses HTTP verbs POST, PUT or PATCH to create or update objects and/or attributes at a SCIM server. The SCIM client is actively "pushing" the data to the endpoint. This SCIM action can occur when the SCIM client is the primary resource creator/updater.

Resource Object creation/update from Client to Server In this model we will have a Client that is going to provide information about a RO and its RA to a Server, that can also be called as SCIM Server in and .

| | | | | | | | (2) | SCIM | | Client | <-------------------------------- | Server | | (typically | | (typically a | | an IdM) | (3) | Application) | | | --------------------------------> | | | RM/RC/RU | | RS | | | (4) | | | | <-------------------------------- | | +----------------+ +----------------+ Figure 3: SCIM Flow and Orchestrator roles maps ]]> Before creating/updating a RO/RA the SCIM client will always do a HTTP GET to get current information from the SCIM Server. SCIM Server will provide the current information on the resources asked by the SCIM Client. Based on the RO and RA returned by the Server, there will be a HTTP POST, PUT, PATCH depending on the operation that the Client want to achieve. The Service Provider will return the RO/RA with additional metadata information to allow for audit. The SCIM client will map to the RM/RC/RU and the Server will map into RS.

Resource Object creation from a Creation Entity In this model we will have a Client that is going to provide information about a RO and its RA to a Server, can also be called as Service Provider in and , in this model the Client is just responsible for a limit set of attributes and do not do any management overall, and the Resource management function resides on the Server.

| | | | | | | | (2) | SCIM | | Client | <-------------------------------- | Server | | (typically | | (typically an | | an HR | (3) | IdM) | | Application) | --------------------------------> | | | | | RM/RS | | RC/RU | (4) | | | | <-------------------------------- | | +--------------+ +---------------+ Figure 4: SCIM Flow and Orchestrator roles maps ]]> Before creating/updating a RO/RA the SCIM client will always do a HTTP GET to get current information from the SCIM Server. SCIM Server will provide the current information on the resources asked by the SCIM Client. Based on the RO and RA returned by the Server, there will be a HTTP POST, PUT, PATCH depending on the operation that the Client want to achieve. The Service Provider will return the RO/RA with additional metadata information to allow for audit. The SCIM client will map to the RC/RU and the Server will map into RM/RS. The SCIM client is sometimes called as the "HR Application", because it responsibilities are only on be the creator and updater of the RO and specific number of its RA, the client in this case has no responsibilities on the management of Resources, typically done by an IdM.

Resource Object creation from a Creation Entity and consumption from an Application In this model we will have a Client that is going to provide information about a RO and its RA to a Server, this Client is just responsible for a limit set of attributes and do not do any management overall the RO. This SCIM element that is going to manage the RO will then be the Client for other SCIM services that will consume the RO/RA, that might have more RA than the original RO provided by the originator of the RO.

| | --------------> | | | Client | |SCIM Server | | | | | (2) | | (2) | SCIM | | | <------------- | | <-------------- | Server | | | | Client| | | | | (3) | | (3) | | | | -------------> | | --------------> | | | | | RM/RS/RC/RU | | | | RC/RU | (4) | | (4) | RS | | | <------------- | | <-------------- | | +--------+ +---------------+ +---------+ Figure 5: SCIM Flow and Orchestrator roles maps ]]> Before creating/updating a RO/RA the SCIM client will always do a HTTP GET to get current information from the SCIM Server. SCIM Server will provide the current information on the resources asked by the SCIM Client. Based on the RO and RA returned by the Server, there will be a HTTP POST, PUT, PATCH depending on the operation that the Client want to achieve. The Service Provider will return the RO/RA with additional metadata information to allow for audit. The SCIM client on the left will map to the RC/RU and the Server in the middle will map into RM/RS, the SCIM client on the left is also sometimes called as the "HR Application", because it responsibilities are only on be the creator and updater of the RO and specific number of its RA, the client in this case has no responsibilities in doing any management of the Resources, typically done by an IdM.
The center component as describe is the Server for the client on the left, will act as the Client for the server on the right, which typically is an SaaS application that want to consume RO and its RA from an RM.

Resource Object creation from a Creation Entity and consumption from an Application when different Resource Attributes are generated in different entities In this model we will have a Client that is going to provide information about a RO and its RA to a Server, this Client is just responsible for a limit set of attributes and do not do any management overall the RO. This SCIM element that is going to manage the RO will then be the Client for other SCIM services that will consume the RO/RA, that might have more RA than the original RO provided by the originator of the RO. Now the right SCIM element will have it own RA that needs to be updated in the RM (Resource Manager), that will also update the SCIM element on the left.

| | -----(1)-----> | | | Client | <----(2)----- |SCIM | <----(2)------ | SCIM | | | -----(3)----> |Server | -----(3)-----> | Server | | | <----(4)----- | Client| <----(4)------ | | | | | | | | | | | | | | | RC/RU/RS | <----(1)----- | RM/RS/RC/RU | <----(1)------ | RS | | | -----(2)----> |Client | -----(2)-----> | | | SCIM | <----(3)----- | SCIM| <----(3)------ | Client | | Server | -----(4)----> | Server| -----(4)-----> | | +----------+ +---------------+ +--------+ Figure 6: SCIM Flow and Orchestrator roles maps ]]> Before creating/updating a RO/RA the SCIM client will always do a HTTP GET to get current information from the SCIM Server. SCIM Server will provide the current information on the resources asked by the SCIM Client. Based on the RO and RA returned by the Server, there will be a HTTP POST, PUT, PATCH depending on the operation that the Client want to achieve. The Service Provider will return the RO/RA with additional metadata information to allow for audit. The SCIM client on the left will map to the RC/RU and the Server in the middle will map into RM/RS, the SCIM client on the left is also sometimes called as the "HR Application", because it responsibilities are only on be the creator and updater of the RO and specific number of its RA, the client in this case has no responsibilities in doing any management of the Resources, typically done by an IdM.
The center component as describe is the Server for the client on the left, will act as the Client for the server on the right, which typically is an SaaS application that want to consume RO and its RA from an RM. In addition to the models seen before now the "HR Application" also subscribe to RA that are created by the RS and reported by the RM, the Application will be the creator of specific attributes.
So we will see that the 3 SCIM elements will be RC/RU/RS for each RO/RA.

Client Active Pull A SCIM client uses the HTTP GET verb to ask for data from a SCIM Server. A client active pull can be used to fetch one object, a subset of objects, or all objects from a SCIM server. In cases where the client is a resource updater, it may perform an active pull of an object or objects in order to determine whether an active push of new data is necessary. Client active pulls can be used in situations where a client needs to maintain a synchronized large body of objects, such as a device list or user address book, but where there isn't any need to track individual RO/RA. Another example of a client active pull would be a client that needs to have details of a specific device that was onboarded by a mobile application and that need to provide the RO/RA information on the behalf of the device.

Resource Object Creation or Update In this model we will have a Client that is going to pull information about a RO/RA from a Server. In this model the Client is going to management all the RO (Resource Objects) and its RA (Resource Attributes), that are provided by the Server, and the RM (Resource Management) function resides on the Client.

| Server | | | | | | | (2) | | | | <-------------------------------- | | | RS/RM | | RC/RU | | | | | | | | | +----------+ +----------+ Figure 7: SCIM Flow and Orchestrator roles maps ]]> The SCIM client will do an HTTP GET to obtain the RO/RA that will be available in the Server. The SCIM Server will return the RO/RA with additional metadata information to allow for audit. A typical example of this use case is a device that is going to use a mobile application or browser base to enroll devices and gathers its attributes, that mobile application or browser after enrollment process is finish will do a trigger to notify the client that is ready to provide the RO/RA of the device. It is the SCIM client that will do al the Resource management for all the devices.
Another example could be a SCIM client that has the role of an IDM that is not the owner of a specific RA and gets it from the Server, for this kind of scenarios the SCIM server would need to create an change database for the attributes that are own by the server

Resources Subscription In this model we will have the Client that is going to pull information about a RO/RA from the Server. In this model, the Client has is no status/change database, and it gets a list of all the RO/RA based on filters provided by the client, so there will be a full update every synchronization cycle.

| | | RC/RU/RM | | RS | | | | | | | | | +----------+ +----------+ Figure 8: SCIM Flow and Orchestrator roles maps ]]> The SCIM client will do an HTTP GET to obtain the selected list of RO (Resource Object) and its RA (Resource Attributes). The SCIM Service Provider will return the RO and its RA with additional metadata information to allow for audit. A good example would be SaaS service that needs to consume a list of contacts or devices, this SaaS service will need to know the relevant RO/RA, this operation will happen periodically and every time will get a full list of all the RO (Resource Objects).

Resource Object Creation or Update and Subscription In this model we will bring together both of the two previous SCIM actions for pull information, where a typically a device can be the creator or their own attributes and will allow an SaaS service to subscribe to all the different RO/RA and deliver additional services for itself and other devices. It isn't expected from any of the SCIM clients in the Active pull model to create any status database of attributes changes, so the clients will always do a pull on one or many RO (Resource Objects) based on triggers.

| | ------------> | | | | | RM/RS/RC/RU | | | | RC/RU | | | | RS | | | | | | | +----------+ +---------------+ +--------+ Figure 9: SCIM Flow and Orchestrator roles maps ]]> The SCIM client will do an HTTP GET to obtain the RO/RA that will be available in the Server. The SCIM Server will return the RO/RA with additional metadata information to allow for audit. The SCIM client will do an HTTP GET to obtain the selected list of RO (Resource Object) and its RA (Resource Attributes). The SCIM Service Provider will return the RO and its RA with additional metadata information to allow for audit. A typical example of this use case is a device that is going to use a mobile application or browser base to enroll devices and gathers its attributes, that mobile application or browser after enrollment process is finish will do a trigger to notify the client that is ready to provide the RO/RA of the device. It is the SCIM client that will do all the Resource management for all the devices.
This SCIM element in the center will also provide list list of contacts or devices, that can be consume by different SCIM entities, this operation will happen when a specific trigger will be execute by the client on the right, to get a list RO (Resource Objects) and RA (Resource Attributes) that will be defined by the filter on the client in the right.

SCIM Use Cases This section describes some common SCIM use cases, explaining when, where, why and how we find them in the cross-domain environment. The ultimate goal is guidance for developers working on common models, explaining challenges and components. Because SCIM is a protocol where two entities exchange information about resources across domains, the use cases explain how the different components can interact to allow from simple to complex architectures for cross domain resource management. Orchestrators roles are mapped to the use cases to simplify the task of explaining the multiple functions of the SCIM elements. Use cases build on each other, starting with simple cases, and ending with the most complex ones.

Self-Referential Resource Updates via /me Get information about persona /me endpoint.
A use case cover in where a SCIM client can do CRUD operation on the entity of the user, in this use case the SCIM client that is the RM (Resource Manager), RC (Resource Creator) and RU (Resource Updater), will be able to read, create, update the RO (Resource Object) and its RA (Resource Attributes) in the RS (Resource Subscriber). the RS will provide an /me URI to achieve this.
Special considerations exist from authorization perspective; unlike other listed CRUD use cases, the authorization for this use case only allows access to the RO (Resource Object) of the resource owner.

Simple Resource Update Single RM/RC/RU and multiple RS.
This is a very common and simple SCIM use case, we have the IdM/Device Managers/etc. do all CRUD operation with the resources, then after the trigger mechanisms the resources information RO/RA reach the RS (Resource Subscribers), also know as the SaaS Application.
The RS (Resource Subscriber) will take the decision on which RA (Resource Attributes) to consider and how the RO (Resource Object) will show in its resource database.
Typically we will find this kind of use case in small to mid size organization, where there is no structure method to handle the resources and typically in Organization that start with a blank sheet of paper in a greenfield deployment.

Resource Updates Originating at a Non-SCIM Source One or more ERC with single RM/RC/RU and multiple RS.
This is another common use case, because it allow the organization to adopt SCIM protocol for CRUD operations of their resources. In this use case the organization already have an existent database of resources that is going to be the source of truth for the Resource Manager.
Normally this ERC, specially if we are talking about user Identity, will have a User database that can be accessible using LDAP, some times the ERC can provide RO/RA using SAML Single Sign-On using Just in time Provision. We also see some IDaaS providing softwares that allow them to exchange resource information by using proprietary protocols, very common using HTTP REST to get the information from the ERC to the RM.
Typically in this use case the RM will become the new source of truth for the resources of our Organization, will add extra RA (Resource Attributes) and ignore other RA that existed in the ERC.
Some organization that already realize that going forward in the SCIM path, the RM will manage the RO/RA, will also start create new RO in the RM.
The Resource Subscribers will consume all or a subset of the RO/RA from the RM.
Typically we will see this use case in small to mid size organization where resources were organized in a non standardize platform for Resources Management, where it isn't possible to cut/replace everything with a new system.

Resources from Multiple SCIM Sources Coordinated by a Resource Manager One or more RC/RU, with single RM/RC/RU/RS and multiple RS.
In this use case, the the CRUD operation for the RO (Resource Object) and its RA (Resource Attributes) does not belong to the RM (Resource Manager), this is done in a separate SCIM entity, the Resource Creator/Resource Updater.
A good example of this is use case are Organization that have their HR application, and the lifecycle of the resource (typically groups and Users) is done by that application.
We could also have devices where the creation and update operations are always done by the device itself or by a mobile application/web server on their behalf, in this use case the roles of RC/RU moves away from the RM. We could also have this use case where the RM is extended with the Roles of RC/RU for extra RA (Resources Attributes), but the RO (Resource Object) is typically created by the "HR System"/device.
Typically we will see this use case in mid to large organization where no structure method to handle the resources start with a blank sheet of paper in a greenfield deployment.

Resources from SCIM and Non-SCIM sources, Coordinated by a Resource Manager One or more ERC, one or more RC/RU, with single RM/RC/RU/RS and multiple RS.
In this use case, one source of the Resource information is an ERC (External Resource Creator), or the entity that has the role of RC/RU (such as an HR System). In some cases the HR system can also consume information from the ERC and complement it. This doesn't mean that the RM will not need to consolidate RO/RA from the SCIM and non SCIM entities and consolidate and aggregate RO/RAs for those multiple sources. The RM gets its RO (Resource Object) from both systems the RC/RU and from the ERC, and need to define rules which ones to take and to ignore.

Complex sources including Multiple Resource Updaters One or more ERC, one or more RC/RU, with single RM/RC/RU/RS and multiple RS/RU.
In this use case we add the capability of the Resource Subscriber to be also an Resource Update, it is very common that an SaaS application can be the source of truth for specifics RA and add extra details to the RO.
Typically we will see this use case in large organization where resources were organized in a non standardize platform for Resources Management and it isn't possible to cut/replace everything with a new system. Those organization start to adopt many application that brings new attributes to the different resources that already exist in the system.

Complex Multi-directional Object and Resource Management with simple Resource Subscribers One or more ERC, one or more RC/RU/RS, with single RM/RC/RU/RS and multiple RS/RU.
In this use case we introduce the possibility of the RC/RU (example given before the HR System) be interested in the attribute that was created updated by the RS/RU (also known as the SaaS application), an example could be adding the business email that was created by the mail service (that came from RS/RU) to the HR information service (the RC/RU/RS element).
Typically we will see this use case in large organization where resources were organized in a non standardize platform for Resources Management and it isn't possible to cut/replace everything with a new system. Those organization start to adopt many application that brings attributes to the different resources that already exist in the system, but they need to have all the important attributes of Resources in a application in our examples "HR application".

Complex Multi-direction Object/Resource Management with bi-directional Resource Subscriber/Updaters One or more ERC, one or more RC/RU/RS, with one or more RM/RC/RU/RS and multiple RS/RU.
In this use case we introduce the possibility of having multiple Resource Managers, where the information from the RO/RA is consolidated across different domains/services.
Typically we will see this use case in large organizations, or between organizations that have their own business to business communication and have the need to exchange information about Resources. This example also happens during mergers or acquisitions, where multiple RMs exist and IT departments have to manage each RM in parallel.