Internet DRAFT - draft-correia-scim-use-cases
draft-correia-scim-use-cases
SCIM P. J. Correia
Internet-Draft Cisco Systems
Intended status: Informational P. Dingle
Expires: 25 April 2024 Microsoft Corporation
23 October 2023
System for Cross-domain Identity Management: Definitions, Overview,
Concepts, and Requirements
draft-correia-scim-use-cases-00
Abstract
This document provides definitions, overview and selected use cases
of the System for Cross-domain Identity Management (SCIM). It lays
out the system's concepts, models, and flows, and it includes use
cases, and implementation considerations.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 25 April 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Correia & Dingle Expires 25 April 2024 [Page 1]
Internet-Draft SCIM Use Cases October 2023
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. SCIM Components and Architecture . . . . . . . . . . . . . . 4
3.1. Evolution and new Challenges . . . . . . . . . . . . . . 5
3.1.1. Reconciliation . . . . . . . . . . . . . . . . . . . 5
3.1.2. HR Applications . . . . . . . . . . . . . . . . . . . 5
3.1.3. Extra RA for RO . . . . . . . . . . . . . . . . . . . 5
3.2. Implementation Concepts . . . . . . . . . . . . . . . . . 6
3.2.1. Data Model . . . . . . . . . . . . . . . . . . . . . 6
3.2.2. HTTP Client-Server Roles . . . . . . . . . . . . . . 6
3.2.3. Orchestrator Roles . . . . . . . . . . . . . . . . . 7
3.2.4. Triggers . . . . . . . . . . . . . . . . . . . . . . 8
3.2.5. SCIM Actions . . . . . . . . . . . . . . . . . . . . 10
4. SCIM Use Cases . . . . . . . . . . . . . . . . . . . . . . . 18
4.1. Self-Referential Resource Updates via /me . . . . . . . . 18
4.2. Simple Resource Update . . . . . . . . . . . . . . . . . 18
4.3. Resource Updates Originating at a Non-SCIM Source . . . . 19
4.4. Resources from Multiple SCIM Sources Coordinated by a
Resource Manager . . . . . . . . . . . . . . . . . . . . 19
4.5. Resources from SCIM and Non-SCIM sources, Coordinated by a
Resource Manager . . . . . . . . . . . . . . . . . . . . 20
4.6. Complex sources including Multiple Resource Updaters . . 20
4.7. Complex Multi-directional Object and Resource Management
with simple Resource Subscribers . . . . . . . . . . . . 20
4.8. Complex Multi-direction Object/Resource Management with
bi-directional Resource Subscriber/Updaters . . . . . . . 21
5. Security Considerations . . . . . . . . . . . . . . . . . . . 21
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction
The System for Cross-domain Identity Management (SCIM) family of
specifications [RFC7643] and [RFC7644] is designed to manage
resources used in the practice of identity management that need to be
communicated across internet domains and services, with users and
groups as the default resources supported (and an extensibility model
additional resource definition). The specifications have two primary
goals: 1) A common representation of a resource object and its
attributes, and 2) Standardized patterns for how those resources can
be operated on, including "CRUD" operations that create, read, update
or delete resource objects and more advanced goals such as search
Correia & Dingle Expires 25 April 2024 [Page 2]
Internet-Draft SCIM Use Cases October 2023
filters, synchronization of large resource populations, etc. These
goals are codified as a data model in [RFC7643] defining resources,
attributes and default schema, as well as a protocol definition built
on HTTP in [RFC7644]. By standardizing the data model and protocol
for resource management, entire ecosystems can achieve better
interoperability, security, and scalability.
This document provides definitions, overview, concepts, flows, and
use cases implementers may need to understand the design and
applicability of the SCIM schema [RFC7643] and SCIM protocol
[RFC7644]. Unlike the practice of some protocols like Application
Bridging for Federated Access Beyond web (ABFAB) and SAML2 WebSSO,
SCIM provides provisioning and de-provisioning of resources in a
separate context from authentication. While SCIM is a protocol that
standardizes movement of data only between two parties in a HTTP
client-server model, implementation patterns are discussed in this
document that use concepts beyond the core schema and protocol, but
that are needed to understand how SCIM actions can fit into greater
architectures.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] when they
appear in ALL CAPS. These words may also appear in this document in
lowercase as plain English words, absent their normative meanings.
Here is a list of acronyms and abbreviations used in this document:
* CRUD: Create, Read, Update, Delete
* RC: Resource Creator
* RU: Resource Updater
* RM: Resource Manager
* RS: Resource Subscriber
* RO: Resource Object
* RA: Resource Attribute
* ERC: External Resource Creator
* IaaS: Infrastructure as a Service
* JIT: Just In Time
Correia & Dingle Expires 25 April 2024 [Page 3]
Internet-Draft SCIM Use Cases October 2023
* PaaS: Platform as a Service
* SaaS: Software as a Service
* IDaaS: Identity as a Service
* IdM: Identity Manager
* SAML: Security Assertion Markup Language
* SCIM: System for Cross-domain Identity Management
* SSO: Single Sign-On
3. 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 [RFC9110] (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.
+---------+ +--------+
| SCIM | | |
| Server | | SCIM |
| | <--- SCIM Action ---> | 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
Correia & Dingle Expires 25 April 2024 [Page 4]
Internet-Draft SCIM Use Cases October 2023
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.
3.1. 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.
3.1.1. 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.
3.1.2. 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.
3.1.3. 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.
Correia & Dingle Expires 25 April 2024 [Page 5]
Internet-Draft SCIM Use Cases October 2023
3.2. 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.
3.2.1. Data Model
SCIM defines two types of data entities: resources and attributes.
3.2.1.1. 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 [RFC7643] and
can be acted on via the endpoints and parameters defined in
[RFC7644].
3.2.1.2. Resource Attribute (RA)
A named element of a Resource Object. Attributes are defined in
section 2 of [RFC7643] and include characteristics like cardinality
(single or multiple values), data types (string, boolean, binary etc)
and characteristics (required, unique etc).
3.2.2. HTTP Client-Server Roles
HTTP client and server roles are defined in [RFC9110] and [RFC9112].
Any SCIM interaction requires one participant to be a SCIM server and
the other to be a SCIM client.
3.2.2.1. 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.
3.2.2.2. 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.
Correia & Dingle Expires 25 April 2024 [Page 6]
Internet-Draft SCIM Use Cases October 2023
3.2.3. 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.
3.2.3.1. 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.
3.2.3.2. 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).
3.2.3.3. 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.
3.2.3.4. 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.
3.2.3.5. 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.
Correia & Dingle Expires 25 April 2024 [Page 7]
Internet-Draft SCIM Use Cases October 2023
+-------------+ +-------------+ +-------------+ +-------------+
|(RO) Resource| |(RA) Resource| |(RO) Resource| |(RA) Resource|
| Object1 | | Attribute1 | | Object2 | | Attribute2 |
+-------------+ +-------------+ +-------------+ +-------------+
| | | |
+-------------+ +-------------+ +-------------+ +-------------+
|(RC) Resource| |(RU) Resource| |(RC) Resource| |(RU) Resource|
| Creators | | Updaters | | Creators | | Updaters |
+-------------+ +-------------+ +-------------+ +-------------+
| | | |
+--------+------+-----------------+-------+--------+
| |
v v
+----------------+ +----------------+
| (RM) Resource | | (RM) Resource |
| Manager | | Manager |
+----------------+ +----------------+
| |
+----------------+ +----------------+
| | | |
v v v v
+-------------+ +-------------+ +-------------+ +-------------+
|(RS) Resource| |(RS) Resource| |(RS) Resource| |(RS) Resource|
| Subscriber | | Subscriber | | Subscriber | | Subscriber |
+-------------+ +-------------+ +-------------+ +-------------+
| |
+----------------+ +----------------+
| | | |
v v v v
+-------------+ +-------------+ +-------------+ +-------------+
|(RO) Resource| |(RO) Resource| |(RO) Resource| |(RO) Resource|
| Object1 | | Object2 | | Object1 | | Object2 |
+-------------+ +-------------+ +-------------+ +-------------+
Figure 1: SCIM Orchestrators Roles
3.2.4. 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.
Correia & Dingle Expires 25 April 2024 [Page 8]
Internet-Draft SCIM Use Cases October 2023
3.2.4.1. 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.
3.2.4.2. 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 [RFC8417] or a SCIM event corresponding to
[SCIM_Profile_for_Security_Event_Tokens]; 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.
3.2.4.3. 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.
3.2.4.4. 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.
Correia & Dingle Expires 25 April 2024 [Page 9]
Internet-Draft SCIM Use Cases October 2023
+---------------+ +---------------+
| | | |
| | | |
| | | SCIM |
| Client | (1) | Server |
| | <-------------------------------> | |
| (typically | | (typically an |
| an IdM) | (2) | SaaS |
| | <-------------------------------> | Application) |
| | | |
| RC/RU/RM | | RS |
| | | |
+---------------+ +---------------+
Figure 2: SCIM Flow and Entities map
1. SSO trigger that creates the user and might create some RA
(Resource Attributes) of a RO (Resource Object)
2. 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.
3.2.5. 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.
3.2.5.1. 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.
Correia & Dingle Expires 25 April 2024 [Page 10]
Internet-Draft SCIM Use Cases October 2023
3.2.5.1.1. 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 [RFC7643] and [RFC7644].
+----------------+ +----------------+
| | (1) | |
| | --------------------------------> | |
| | | |
| | (2) | SCIM |
| Client | <-------------------------------- | Server |
| (typically | | (typically a |
| an IdM) | (3) | Application) |
| | --------------------------------> | |
| RM/RC/RU | | RS |
| | (4) | |
| | <-------------------------------- | |
+----------------+ +----------------+
Figure 3: SCIM Flow and Orchestrator roles maps
1. Before creating/updating a RO/RA the SCIM client will always do a
HTTP GET to get current information from the SCIM Server.
2. SCIM Server will provide the current information on the resources
asked by the SCIM Client.
3. 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.
4. 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.
3.2.5.1.2. 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 [RFC7643] and [RFC7644], 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.
Correia & Dingle Expires 25 April 2024 [Page 11]
Internet-Draft SCIM Use Cases October 2023
+--------------+ +---------------+
| | (1) | |
| | --------------------------------> | |
| | | |
| | (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
1. Before creating/updating a RO/RA the SCIM client will always do a
HTTP GET to get current information from the SCIM Server.
2. SCIM Server will provide the current information on the resources
asked by the SCIM Client.
3. 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.
4. 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.
3.2.5.1.3. 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.
Correia & Dingle Expires 25 April 2024 [Page 12]
Internet-Draft SCIM Use Cases October 2023
+--------+ +---------------+ +---------+
| | (1) | | (1) | |
| | -------------> | | --------------> | |
| 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
1. Before creating/updating a RO/RA the SCIM client will always do a
HTTP GET to get current information from the SCIM Server.
2. SCIM Server will provide the current information on the resources
asked by the SCIM Client.
3. 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.
4. 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.
Correia & Dingle Expires 25 April 2024 [Page 13]
Internet-Draft SCIM Use Cases October 2023
3.2.5.1.4. 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)----> | | -----(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
1. Before creating/updating a RO/RA the SCIM client will always do a
HTTP GET to get current information from the SCIM Server.
2. SCIM Server will provide the current information on the resources
asked by the SCIM Client.
3. 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.
4. 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
Correia & Dingle Expires 25 April 2024 [Page 14]
Internet-Draft SCIM Use Cases October 2023
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.
3.2.5.2. 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 [Device_Schema_Extensions_to_the_SCIM_model] that was
onboarded by a mobile application and that need to provide the RO/RA
information on the behalf of the device.
3.2.5.2.1. 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.
+----------+ +----------+
| | | |
| | | |
| | | |
| SCIM | (1) | SCIM |
| Client | --------------------------------> | Server |
| | | |
| | (2) | |
| | <-------------------------------- | |
| RS/RM | | RC/RU |
| | | |
| | | |
+----------+ +----------+
Figure 7: SCIM Flow and Orchestrator roles maps
Correia & Dingle Expires 25 April 2024 [Page 15]
Internet-Draft SCIM Use Cases October 2023
1. The SCIM client will do an HTTP GET to obtain the RO/RA that will
be available in the Server.
2. 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
3.2.5.2.2. 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.
+----------+ +----------+
| | | |
| | | |
| | | |
| SCIM | (1) | |
| Server | <-------------------------------- | Client |
| | | |
| | (2) | |
| | --------------------------------> | |
| RC/RU/RM | | RS |
| | | |
| | | |
+----------+ +----------+
Figure 8: SCIM Flow and Orchestrator roles maps
1. The SCIM client will do an HTTP GET to obtain the selected list
of RO (Resource Object) and its RA (Resource Attributes).
2. The SCIM Service Provider will return the RO and its RA with
additional metadata information to allow for audit.
Correia & Dingle Expires 25 April 2024 [Page 16]
Internet-Draft SCIM Use Cases October 2023
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).
3.2.5.2.3. 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.
+----------+ +---------------+ +--------+
| | | | | |
| | | | | |
| | | | | |
| SCIM | (1) |Client | (3) | |
| Server | <-------------- | SCIM| <------------ | Client |
| | | Server| | |
| | (2) | | (4) | |
| | --------------> | | ------------> | |
| | | RM/RS/RC/RU | | |
| RC/RU | | | | RS |
| | | | | |
+----------+ +---------------+ +--------+
Figure 9: SCIM Flow and Orchestrator roles maps
1. The SCIM client will do an HTTP GET to obtain the RO/RA that will
be available in the Server.
2. The SCIM Server will return the RO/RA with additional metadata
information to allow for audit.
3. The SCIM client will do an HTTP GET to obtain the selected list
of RO (Resource Object) and its RA (Resource Attributes).
4. 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
Correia & Dingle Expires 25 April 2024 [Page 17]
Internet-Draft SCIM Use Cases October 2023
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.
4. 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.
4.1. Self-Referential Resource Updates via /me
Get information about persona /me endpoint.
A use case cover in [RFC7644] 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.
4.2. 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
Correia & Dingle Expires 25 April 2024 [Page 18]
Internet-Draft SCIM Use Cases October 2023
resources and typically in Organization that start with a blank sheet
of paper in a greenfield deployment.
4.3. 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.
4.4. 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
Correia & Dingle Expires 25 April 2024 [Page 19]
Internet-Draft SCIM Use Cases October 2023
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.
4.5. 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.
4.6. 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.
4.7. 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
Correia & Dingle Expires 25 April 2024 [Page 20]
Internet-Draft SCIM Use Cases October 2023
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".
4.8. 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.
5. Security Considerations
Authentication and authorization must be guaranteed for the SCIM
operations to ensure that only authenticated entities can perform the
SCIM requests and the requested SCIM operations are authorized. SCIM
resources (e.g., Users and Groups) can contain sensitive information.
Thus, data confidentiality MUST be guaranteed at the transport layer.
There can be privacy issues that go beyond transport security, e.g.,
moving personally identifying information (PII) offshore between
different SCIM elements. Regulatory requirements shall be met when
migrating identity information between jurisdictional regions (e.g.,
countries and states may have differing regulations on privacy).
Additionally, privacy-sensitive data elements may be omitted or
obscured in SCIM transactions or stored records to protect these data
elements for a user. For instance, a role-based identifier might be
used in place of an individual's name. Detailed security
considerations are specified in Section 7 of the SCIM protocol
[RFC7644] and Section 9 of the SCIM schema [RFC7643].
6. IANA Considerations
There are no additional IANA considerations to those specified
[RFC7643] and [RFC7644].
Correia & Dingle Expires 25 April 2024 [Page 21]
Internet-Draft SCIM Use Cases October 2023
7. Acknowledgements
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
8.2. Informative References
[RFC7643] Hunt, P., Ed., Grizzle, K., Wahlstroem, E., and C.
Mortimore, "System for Cross-domain Identity Management:
Core Schema", RFC 7643, DOI 10.17487/RFC7643, September
2015, <https://www.rfc-editor.org/rfc/rfc7643>.
[RFC7644] Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E.,
and C. Mortimore, "System for Cross-domain Identity
Management: Protocol", RFC 7644, DOI 10.17487/RFC7644,
September 2015, <https://www.rfc-editor.org/rfc/rfc7644>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/rfc/rfc9110>.
[RFC9112] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
June 2022, <https://www.rfc-editor.org/rfc/rfc9112>.
[RFC8417] Hunt, P., Ed., Jones, M., Denniss, W., and M. Ansari,
"Security Event Token (SET)", RFC 8417,
DOI 10.17487/RFC8417, July 2018,
<https://www.rfc-editor.org/rfc/rfc8417>.
[Device_Schema_Extensions_to_the_SCIM_model]
Shahzad, M., Iqbal, H., and E. Lear, "Device Schema
Extensions to the SCIM model", July 2023,
<https://datatracker.ietf.org/doc/draft-shahzad-scim-
device-model>.
[SCIM_Profile_for_Security_Event_Tokens]
Hunt, P., Cam-Winget, N., and M. Kiser, "Device Schema
Extensions to the SCIM model", July 2023,
<https://datatracker.ietf.org/doc/draft-ietf-scim-events>.
Correia & Dingle Expires 25 April 2024 [Page 22]
Internet-Draft SCIM Use Cases October 2023
Authors' Addresses
Paulo Jorge Correia
Cisco Systems
Email: paucorre@cisco.com
Pamela Dingle
Microsoft Corporation
Email: pamela.dingle@microsoft.com
Correia & Dingle Expires 25 April 2024 [Page 23]
