RFC 7642

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

📅 published September 2015, from ietf

RFC 7642 🎀 Part 1 of 4

Okay bestie, this one is RFC 7642, titled "System for Cross-domain Identity Management: Definitions, Overview, Concepts, and Requirements" 💖. It's an Informational doc (ISSN 2070-1721), published September 2015 by the IETF. The editor is K. Li from Alibaba Group, and the other authors are P. Hunt (Oracle), B. Khasnabish (ZTE (TX) Inc.), A. Nadalin (Microsoft), and Z. Zeltsan (Individual). The title block doesn't list anything it obsoletes or updates 🦋.

Abstract ✨

This doc gives you the definitions and the big-picture overview of the System for Cross-domain Identity Management (SCIM) 🌸. It lays out the system's concepts, models, and flows, and it's packed with user scenarios, use cases, and requirements 💅.

Status of This Memo 🌈

Quick heads up: this is not an Internet Standards Track spec. It's published just for info 🧚.

It's a product of the Internet Engineering Task Force (IETF) and reflects the consensus of the IETF community. It got public review and was approved by the Internet Engineering Steering Group (IESG) 👑. Not every IESG-approved doc is up for any level of Internet Standard, so check out Section 2 of RFC 5741 if you want the details 🙈.

For the current status, errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7642 💜.

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved 🫶.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read those, because they spell out your rights and restrictions for this doc 📜. Any Code Components pulled out of this doc have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License 🔥.

Table of Contents 🍓

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
  1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
2.  SCIM User Scenarios . . . . . . . . . . . . . . . . . . . . .   5
  2.1.  Background and Context  . . . . . . . . . . . . . . . . .   5
  2.2.  Model Concepts  . . . . . . . . . . . . . . . . . . . . .   5
    2.2.1.  Triggers  . . . . . . . . . . . . . . . . . . . . . .   5
    2.2.2.  Actors  . . . . . . . . . . . . . . . . . . . . . . .   6
    2.2.3.  Modes and Flows . . . . . . . . . . . . . . . . . . .   7
    2.2.4.  Bulk and Batch Operational Semantics  . . . . . . . .   8
  2.3.  Flows from Cloud Service Provider to Cloud Service
        Provider (CSP->CSP) . . . . . . . . . . . . . . . . . . .   8
    2.3.1.  CSP->CSP: Create Identity (Push)  . . . . . . . . . .   8
    2.3.2.  CSP->CSP: Update Identity (Push)  . . . . . . . . . .   9
    2.3.3.  CSP->CSP: Delete Identity (Push)  . . . . . . . . . .   9
    2.3.4.  CSP->CSP: SSO Trigger (Push)  . . . . . . . . . . . .   9
    2.3.5.  CSP->CSP: SSO Trigger (Pull)  . . . . . . . . . . . .  10
    2.3.6.  CSP->CSP: Password Reset (Push) . . . . . . . . . . .  10
  2.4.  Flows from Enterprise Cloud Subscriber to Cloud Service
        Provider    (ECS->CSP)  . . . . . . . . . . . . . . . . .  10
    2.4.1.  ECS->CSP: Create Identity (Push)  . . . . . . . . . .  10
    2.4.2.  ECS->CSP: Update Identity (Push)  . . . . . . . . . .  11
    2.4.3.  ECS->CSP: Delete Identity (Push)  . . . . . . . . . .  11
    2.4.4.  ECS->CSP: SSO Trigger (Pull)  . . . . . . . . . . . .  11
3.  SCIM Use Cases  . . . . . . . . . . . . . . . . . . . . . . .  11
  3.1.  Migration of the Identities . . . . . . . . . . . . . . .  11
  3.2.  Single Sign-On (SSO) Service  . . . . . . . . . . . . . .  12
  3.3.  Provisioning of the User Accounts for a Community of
        Interest (COI)  . . . . . . . . . . . . . . . . . . . . .  14
  3.4.  Transfer of Attributes to a Relying Party's Website . . .  15
  3.5.  Change Notification . . . . . . . . . . . . . . . . . . .  16
4.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
  5.1.  Normative References  . . . . . . . . . . . . . . . . . .  18
  5.2.  Informative References  . . . . . . . . . . . . . . . . .  18
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  18
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

1. Introduction ✨

This doc is where you'll find the SCIM definitions, overview, concepts, flows, scenarios, and use cases 🦋. It also has a list of requirements that come out of those use cases 💅.

The point of the doc is to help you understand how the SCIM schema [RFC7643] and the SCIM protocol [RFC7644] are designed and where they apply 🎀.

Here's the fun bit: some protocols, like Application Bridging for Federated Access Beyond web (ABFAB) and SAML2 WebSSO, don't do this. SCIM handles provisioning and de-provisioning of resources in a separate context from authentication, which is also called just-in-time provisioning 🧚.

1.1. Terminology 💜

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be read as described in [RFC2119] when they show up in ALL CAPS 🔥. They can also show up in lowercase as regular English words, with no normative meaning attached 🙈.

Here's a list of the acronyms and abbreviations used in this doc 🍓:

  • COI: Community of Interest
  • CRM: Customer Relationship Management
  • CRUD: Create, Read, Update, Delete
  • CSP: Cloud Service Provider
  • CSU: Cloud Service User
  • ECS: Enterprise Cloud Subscriber
  • IaaS: Infrastructure as a Service
  • JIT: Just In Time
  • PaaS: Platform as a Service
  • SaaS: Software as a Service
  • SAML: Security Assertion Markup Language
  • SCIM: System for Cross-domain Identity Management
  • SSO: Single Sign-On

2. SCIM User Scenarios 🌸

2.1. Background and Context 🫶

The System for Cross-domain Identity Management (SCIM) spec is built to manage user identity in cloud-based apps and services in a standardized way, so things are interoperable, secure, and scalable 💖. The spec suite builds on what already exists in schemas and deployments, and it puts real emphasis on simplicity of development and integration while still applying existing authentication, authorization, and privacy models ✨. The goal is to cut the cost and complexity of user management by giving you a common user schema and extension model, plus binding docs that show how to exchange that schema over standard protocols 👑. Basically, the vision is to make it fast, cheap, and easy to move users in to, out of, and around the cloud 🚀.

The SCIM scenarios are overviews of user stories that help clarify the intended scope of the SCIM effort 🦋.

2.2. Model Concepts 💅

2.2.1. Triggers 🎀

Quite simply, triggers are the actions or activities that kick off SCIM flows 🧚. They might not matter at the protocol level or the schema level. Really, they just help identify the type of activity that led to a SCIM protocol exchange 💜. Triggers use the traditional provisioning CRUD (Create, Read, Update, Delete) operations, but they add use-case contexts like SSO (Single-Sign On) on top. That's because they capture a class of use case that makes sense to whoever is asking for it, rather than describing a protocol operation 🙈.

  • Create SCIM Identity Resource - Service On-boarding Trigger: A "create SCIM identity resource" trigger is a service on-boarding activity. A business action, like a new hire or a new service subscription, gets started by one of the SCIM Actors 🍓. At the protocol level, service on-boarding may well be implemented with the same resource PUT method used for a service change. That's a detail of the implementation, not of the use cases driving it 🔥.
  • Update SCIM Identity Resource - Service Change Trigger: An "update SCIM identity resource" trigger is a service change that happens when an identity moves or changes its service level 🌈. It might come from a change in a service subscription level, or from a change to key identity data that marks a service subscription level 💖. Password changes get called out separately from other general identity attribute changes, since they're considered to have specific use-case differences 🫶.
  • Delete SCIM Identity Resource - Service Termination Trigger: A "delete SCIM identity resource" trigger is a specific, deliberate action that removes an identity from a given SCIM service point 💀. For now, it's unclear whether the SCIM protocol needs a separate protocol exchange for service suspension actions 🤔. That could matter, because target services usually tell these results apart and may need separate resource representations ✨.
  • Single Sign-On (SSO) Trigger - Service Access Request: A "Single Sign-On" trigger is a special kind of activity where a Create or Update trigger starts during an SSO operational flow 👑. The idea is that when an end user makes a service access request (SSO), the defined SCIM protocol exchanges can be used to kick off SCIM resource CRUD operations somewhere in the service cloud 🧚.

(Part 1 of 4 💖 more coming soon, bestie 🦋)

2.2.2. Actors ✨

okay so Actors are the operating parties that show up on both sides of a SCIM protocol exchange 🫶 and they help us figure out where a given Trigger actually came from. so far we've got three of them:

  • Cloud Service Provider (CSP): the CSP is the entity running a given cloud service 💅 in a SaaS setup, that's literally just the application provider. in an IaaS or PaaS setup, the CSP could be the underlying IaaS/PaaS infrastructure provider OR the owner of the app running on that platform. either way, the CSP is the one holding the identity info being operated on. put another way, the CSP is the service the end user actually interacts with 🌸
  • Enterprise Cloud Subscriber (ECS): the ECS is a middle tier that groups related identity records together 🧚 in one of our sample enterprise SaaS scenarios, the ECS is "Example.com", which subscribes to a cloud-based CRM service "SaaS-CRM Inc." (the CSP) for all of its sales staff. the actual Cloud Service Users (CSUs) are the FooBar Inc. sales staff. we added the ECS Actor so we can capture use cases where one entity has administrative responsibility over other identity accounts 👑 SCIM might not cover how an ECS gets configured and set up inside the CSP, but it does cover cases where SCIM identity resources are grouped together and managed as part of some broader agreement or operational exchange 💜
  • Cloud Service User (CSU): the CSU is the real cloud service end user, aka the actual person logging in and using the service 🍓 like we said before, an ECS will usually own or manage multiple CSU identities, and the CSU here is the FooBar Inc. employee using the cloud service to manage their CRM process 😭
                       +---------------------+
                       |   Cloud Service     |
                       |   Provider (CSP)    |
                       +---------------------+
                                  |
                +--------------------------------+
                |                                |
                v                                v
        +----------------+              +----------------+
        |Enterprise Cloud|              |Enterprise Cloud|
        |Subscriber (ECS)|              |Subscriber (ECS)|
        +----------------+              +----------------+
                |                                |
        +----------------+              +----------------+
        |                |              |                |
        v                v              v                v
+-------------+ +-------------+   +-------------+ +-------------+
|Cloud Service| |Cloud Service|   |Cloud Service| |Cloud Service|
|  User (CSU) | |  User (CSU) |   |  User (CSU) | |  User (CSU) |
+-------------+ +-------------+   +-------------+ +-------------+

                       Figure 1: SCIM Actors

2.2.3. Modes and Flows 🦋

Modes tell us the functional intent of a data flow kicked off in a SCIM scenario 💖 the modes we've identified so far are 'Push' and 'Pull', which mean pushing data to and pulling data from an authoritative identity data store.

in the SCIM scenarios, modes usually show up in the context of a flow between two Actors 🎀 for example, you might hear someone say "Cloud-to-Cloud Pull" exchange. that means one Cloud Service Provider (CSP) is pulling identity info from another CSP. the commonly referenced flows are:

  • Cloud Service Provider to Cloud Service Provider (CSP->CSP)
  • Enterprise Cloud Subscriber to Cloud Service Provider (ECS->CSP)
modes and flows are basically just vibes for understanding what's going on 🧠 they're probably technically meaningless at the protocol level, but they help the reader follow the SCIM scenarios and map them onto real-world use cases. no cap, they're a reading tool, not a protocol feature 🫠

2.2.4. Bulk and Batch Operational Semantics 🌈

it's assumed that each of the trigger actions in this document may be part of a larger bulk or batch operation 💅 individual SCIM actions should be able to be collected together to make single protocol exchanges. iconic energy ✨

the initial focus of SCIM scenarios is on identifying base flows and single operations 🧚 the specific complexity of full bulk and batch operations gets left for a later version of the scenarios or for the main specification. not today, bestie 💀

2.3. Flows from Cloud Service Provider to Cloud Service Provider (CSP->CSP) 👑

these scenarios are about flows between two Cloud Service Providers (CSPs) 🫶 it's assumed that each CSP keeps an Identity Data Store for its Cloud Service Users (CSUs) 💜 these scenarios cover various joiner, mover, leaver, and JIT triggers, which end up as push and pull data exchanges between the CSPs. main character energy 🌸

2.3.1. CSP->CSP: Create Identity (Push) 🎀

in this scenario, two CSPs (CSP-1 and CSP-2) have a shared service agreement that requires swapping Cloud Service User (CSU) accounts 💖 CSP-1 gets a Create Identity trigger action from its Enterprise Cloud Subscriber (ECS-1). CSP-1 makes a local user account for the new CSU 🧚 then CSP-1 pushes the new CSU joiner push request downstream to CSU-2 and waits to get confirmation that the account was successfully created. once CSP-1 gets that confirmation from CSP-2, it sends an acknowledgment back to the requesting ECS 🫶

2.3.2. CSP->CSP: Update Identity (Push) 🦋

same vibe here: two CSPs (CSP-1 and CSP-2) have a shared service agreement that requires the exchange of Cloud Service User (CSU) accounts 🍓 the Enterprise Cloud Subscriber (ECS-1) already created an account with CSP-1 and supplied a critical attribute "department" that CSP-1 uses to drive service options 💅 then CSP-1 gets an Update Identity trigger action from its Enterprise Cloud Subscriber (ECS). CSP-1 updates its local directory account with the new department value. after that, CSP-1 starts a separate SCIM protocol exchange to push the mover change request downstream to CSP-2 🔥 once CSP-1 gets confirmation from CSP-2, it sends an acknowledgment to ECS-1 ✨

2.3.3. CSP->CSP: Delete Identity (Push) 💀

in this scenario, two CSPs (CSP-1 and CSP-2) have a shared service agreement that requires the exchange of Cloud Service User (CSU) accounts 🌈 CSP-1 gets a Delete Identity trigger action from its Enterprise Cloud Subscriber (ECS-1). CSP-1 suspends the local directory account for the specified CSU account 🙈 then CSP-1 pushes a termination request for that CSU account downstream to CSP-2 and waits to get confirmation that the account was successfully removed. once CSP-1 has that confirmation from CSP-2, it finalizes the deletion operation and sends an acknowledgment to the requesting ECS 🎀

this use case is a great example of how different CSPs can implement different operational semantics behind the same SCIM operation 🫠 note that CSP-1 suspends the account representation for its service, whereas CPS-2 implements a true delete operation.

2.3.4. CSP->CSP: SSO Trigger (Push) 🧚

in this scenario, two CSPs (CSP-1 and CSP-2) have a shared service agreement that requires the exchange of Cloud Service User (CSU) accounts 💖 but instead of pre-provisioning accounts from CSP-1 to CSP-2, CSP-1 waits for a service access request from the end Cloud Service User (CSU-1) before it issues account creation details to CSP-2 😭 when the CSU completes an SSO transaction from CSP-1 to CSP-2, CSP-2 creates an account for the CSU based on info pushed to it from CSP-1 👑

at the protocol level, this class of scenarios may result in the use of common protocol exchange patterns between CSP-1 and CSP-2 🦋

2.3.5. CSP->CSP: SSO Trigger (Pull) 🌸

in this scenario, two CSPs (CSP-1 and CSP-2) have a shared service agreement that requires the exchange of Cloud Service User (CSU) accounts 💅 but instead of pre-provisioning accounts from CSP-1 to CSP-2, CSP-2 waits for a service access request from the Cloud Service User (CSU-1) before it starts a Pull request to gather info about the CSU, enough to create a local account 🍓

at the protocol level, this class of scenarios may result in the use of common protocol exchange patterns between CSP-2 and CSP-1 🫶

2.3.6. CSP->CSP: Password Reset (Push) 🔥

in this scenario, two CSPs (CSP-1 and CSP-2) have a shared service agreement that requires the exchange of Cloud Service User (CSU) accounts 🌈 CSP-1 wants to change the password for a specific Cloud Service User (CSU-1). CSP-1 sends a request to CSP-2 to reset the password value for CSU-1 🙈

at the protocol level, this scenario may result in the same protocol exchange as any other attribute change request 💜

2.4. Flows from Enterprise Cloud Subscriber to Cloud Service Provider (ECS->CSP) 🧚

these scenarios are about flows between an Enterprise Cloud Subscriber (ECS) and a Cloud Service Providers (CSP) 💖 it's assumed that the ECS and the CSP each keep an information access service for the relevant Cloud Service Users (CSUs) 🎀 these scenarios cover various joiner, mover, leaver, and JIT triggers, which end up as push and pull data exchanges between the ECS and the CSP ✨

many of these scenarios are very similar to the ones in Section 2.3. they're listed separately here so we can explore any differences that might pop up 🦋

2.4.1. ECS->CSP: Create Identity (Push) 🫶

in this scenario, an Enterprise Cloud Subscriber (ECS-1) maintains a service with a Cloud Service Provider (CSP-1) that requires sharing various Cloud Service User (CSU) accounts 🌸 a new user joins ECS-1, so ECS-1 pushes an account creation request to CSP-1, supplying all required attribute values for the base SCIM schema and additional values for the extended SCIM schema as required 💅

2.4.2. ECS->CSP: Update Identity (Push) 🍓

in this scenario, an Enterprise Cloud Subscriber (ECS-1) maintains a service with Cloud Service Provider (CSP-1) that drives service definition from a key account schema attribute called Department 🔥 ECS-1 wants to move a given CSU from Department A to Department B, so it pushes an attribute update request to the CSP 🌈

2.4.3. ECS->CSP: Delete Identity (Push) 🙈

in this scenario, an Enterprise Cloud Subscriber (ECS-1) maintains a service with a Cloud Service Provider (CSP-1). when one of its employees' employment agreement ends, ECS-1 sends a suspend account request to CSP-1 💀 one week later, the ECS wants to finish the process by fully removing the Cloud Service User (CSU) account, so it sends a terminate account request to CSP-1 🫠

2.4.4. ECS->CSP: SSO Trigger (Pull) 💜

in this scenario, an Enterprise Cloud Subscriber (ECS-1) maintains a service with a Cloud Service Provider (CSP-1). no accounts are created or exchanged in advance 🧚 but instead of pre-provisioning accounts from ECS-1 to CSP-1, CSP-1 waits for a service access request from the Cloud Service User (CSU-1) under the control domain of ECS-1, and only then issues an account Pull request to ECS-1 🎀

3. SCIM Use Cases 🌈

this section lists the SCIM use cases 💖

3.1. Migration of the Identities 🦋

Okay so picture this: SomeEnterprise has an app called ManageThem that runs on info about its employees (identifiers, attributes, the works 💅). That identity info currently lives in the cloud of SomeCSP. SomeEnterprise decides to move it over to a totally different provider, AnotherCSP. Meanwhile they also bought a second app, ManageThemMore, that needs the same identity info too 🎀. The best part is that SomeEnterprise can move everything to AnotherCSP without changing the format of the identity data, and ManageThemMore can still read it. Iconic. ✨

Pre-conditions:

  • SomeCSP is a cloud service provider for SomeEnterprise.
  • SomeCSP has a known attribute name and value for the Enterprise used for managing and transferring data.
  • AnotherCSP is a new cloud service provider for SomeEnterprise.
  • All involved cloud service providers and applications support the same standard specifying the format for and actions on the user (e.g., employee) identity information.

Post-conditions:

  • SomeEnterprise has moved its employees' identity information from SomeCSP to AnotherCSP without making any changes to representation of identity information.
  • Application ManageThemMore is able to use the identity information.

Requirements:

  • SomeEnterprise, the applications ManageThem and ManageThemMore, and the providers SomeCSP and AnotherCSP support a common standard for identity information, which specifies the following:
    • Format (or schema) for representing user identity information
    • Interfaces and protocol for managing user identity information
  • Cloud providers shall be able to meet regulatory requirements when migrating identity information between jurisdictional regions (e.g., countries and states may have differing regulations on privacy).
  • Cloud providers shall be able to log all actions related to SomeEnterprise employees' identities.
  • The logs should be secure and available for auditing.

3.2. Single Sign-On (SSO) Service 🔑

Bob has an account in an app hosted by SomeCSP. SomeCSP has federated its user identities with AnotherCSP. Now Bob wants a service from an app running on AnotherCSP. That app trusts SomeCSP to vouch for Bob and uses the identity info SomeCSP gives it, so Bob gets his service served up without a second login. Main character energy, honestly 👑

Pre-conditions:

  • Bob's identity information is stored on SomeCSP.
  • SomeCSP and AnotherCSP have established trust and federated their user identities.
  • SomeCSP is able to authenticate Bob.
  • SomeCSP is able to securely provide the authentication results to AnotherCSP.
  • SomeCSP is able to securely provide Bob's identity information (e.g., attributes) to AnotherCSP.
  • AnotherCSP is able to verify information provided by SomeCSP.
  • SomeCSP is able to process the identity information received from AnotherCSP.

Post-conditions:

Bob has received the requested service from an application running on AnotherCSP without having to authenticate to that application explicitly. 🎉

Requirements:

  • Bob must have an account with SomeCSP.
  • SomeCSP and AnotherCSP must establish trust and federate their user identities.
  • SomeCSP must be able to authenticate Bob.
  • SomeCSP must be able to securely provide the authentication results to AnotherCSP.
  • SomeCSP must be able to securely provide Bob's identity information (e.g., attributes) to AnotherCSP.
  • AnotherCSP must be able to verify the identity information provided by SomeCSP.
  • SomeCSP must be able to process the identity information received from AnotherCSP.
  • SomeCSP and AnotherCSP must log information generated by Bob's actions according to their policies and the trust agreement between them.

3.3. Provisioning of the User Accounts for a Community of Interest (COI) 🌍

So YourHR is an organization that does HR services for a Community of Interest called YourCOI 💼. The HR stuff is offered as SaaS on public and private clouds, and YourCOI's offices are literally all over the world 🧚. Their IT is a messy mix of apps on private and public clouds plus old-school traditional systems, and it's giving complicated. The local YourCOI offices collect personal info (user identities and attributes), and YourHR handles provisioning and spreading that employee identity info across every office. YourHR also lets individual users manage the personal info they're responsible for, like updating an address or phone number. Empowerment era 🙌

Pre-conditions:

  • YourCOI has a complex infrastructure composed of a large number of local offices that rely on diverse IT systems.
  • YourCOI has contracted YourHR to provide the HR services.
  • Each local office has a right to establish a personal account for an employee.

Post-conditions:

  • All personal accounts are globally available to any authorized user or application across the YourCOI system through the services provided by YourHR.
  • The employees have the ability to manage the part of personal information that is their responsibility.

Requirements:

  • YourHR must ensure that the local offices generate information that is provisioned securely and consider privacy requirements in a timely fashion across systems that may span technical (e.g., protocols and applications), administrative (e.g., corporate), regulatory (e.g., location), and jurisdictional domains.
  • Management of personal information must be protected against unauthorized access and eavesdropping, and it should be distributed only to authorized parties and services.
  • Regulatory requirements shall be met when migrating identity information between jurisdictional regions (e.g., countries and states may have differing regulations on privacy).
  • All operations with identity data must be securely logged.
  • The logs should be available for auditing.

3.4. Transfer of Attributes to a Relying Party's Website 📦

An end user has an account in directory service A with one or more attributes. Then they visit the website of relying party B, which wants some of those attributes. The user picks what to share and authorizes the transfer through authorization protocols (e.g., OAuth, SAML), so the chosen attributes move from directory service A to B's website on that very first visit. Consent is everything, bestie 🫶

Pre-conditions:

  • User has an account in directory service A.
  • User has one or more attributes.
  • User visits website of relying party B.

Post-conditions:

Selected attributes of the user are transferred from the user's account in directory service A to the website of relying party B at the time of the user's first visit to that site.

Requirements:

  • Relying party B must be able to authenticate the end user.
  • Relying party B must be able to securely provide the authentication results to directory service A.
  • Directory service A must be able to securely provide end user's identity information (e.g., attributes) to relying party B.
  • Regulatory requirements shall be met when migrating identity information between jurisdictional regions (e.g., countries and states may have differing regulations on privacy).
  • Relying parties have to be aware of changes to their cached copy, as these would potentially cause a state change in other relying parties.
  • A maximum period should be set for the relying party to cache the information.

3.5. Change Notification 🔔

Same setup as before: an end user has an account in directory service A with some attributes, and they visit relying party B's website. B asks directory service A for that user's attributes and related resources 👀. Later, the user's attributes change in A. Maybe they changed their name, got their account disabled, or ended their relationship with A. Other resources and their attributes might change too. A wants to tell B about all this, because B might have a cached copy, and if B found out about those changes, its cached copy could cause a state change in B.

The volume of changes can be huge, though, and only some of them are relevant to B. So A doesn't want to just "push" everything at B 🙅‍♀️. Instead, A tells B that there are changes that might be of interest. Then B can come back at a good time and pull down only the subset it cares about. Smart, right? 🧠

Heads up: the user must authorize directory service A to transfer data to the website, and the user must authorize directory service A to notify the website. Consent, consent, consent 💖

Pre-conditions:

  • User has an account in directory service A.
  • User has one or more attributes.
  • User visits the website of relying party B.
  • The resource being updated is at the website.

Post-conditions:

Directory service A is able to notify relying party B that there are changes potentially of interest.

Requirements:

  • Relying party B must be able to authenticate the end user.
  • Relying party B must be able to securely provide the authentication results to directory service A.
  • Directory service A must be able to securely provide end user's changed identity information (e.g., attributes) to relying party B.
  • Relying party B must be able at an appropriate time to subsequently contact directory service A and retrieve just the subset of changes of interest to relying party B.

4. Security Considerations 🔐

Okay, this part is serious, so no fooling around 🥹. Authentication and authorization must be guaranteed for the SCIM operations, so only authenticated entities can make SCIM requests and the requested SCIM operations are authorized. No exceptions.

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 CSPs. Regulatory requirements shall be met when migrating identity information between jurisdictional regions (e.g., countries and states may have differing regulations on privacy). 🌏

Privacy-sensitive data elements may also be omitted or obscured in SCIM transactions or stored records to protect them 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]. 📚

5. References 📖

5.1. Normative References 📚

okay so this is the "you really need to read these" list 💅

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

5.2. Informative References 🦋

these are the extra reads that give you the full picture, no cap 🧚

[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, <http://www.rfc-editor.org/info/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, <http://www.rfc-editor.org/info/rfc7644>.

Acknowledgments ✨

okay the authors really wanted to shout out their besties 🫶 Thank you to Ray Counterman, Richard Fiekowsky, Bert Greevenbosch, Barry Leiba, Kelly Grizzle, Magnus Nystrom, Stephen Farrell, Kathleen Moriarty, Benoit Claise, Dapeng Liu, and Jun Li for reviewing and commenting. 💖

Also, huge thanks to Darran Rolls and Patrick Harding 👑 Section 2 ("SCIM User Scenarios") was taken from them, so they get all the credit for those scenarios 🌸

Authors' Addresses 🎀

here's who wrote it, with all the contact details 💜

Kepeng LI (editor)
Alibaba Group
969 Wenyixi Road, Yuhang District
Hangzhou, Zhejiang  311121
China

Email: kepeng.lkp@alibaba-inc.com


Phil Hunt
Oracle

Email: phil.hunt@oracle.com


Bhumip Khasnabish
ZTE (TX) Inc.
55 Madison Ave, Suite 302
Morristown, New Jersey  07960
United States

Phone: +001-781-752-8003
Email: vumip1@gmail.com, bhumip.khasnabish@ztetx.com
URI:   http://tinyurl.com/bhumip/


Anthony Nadalin
Microsoft

Email: tonynad@microsoft.com


Zachary Zeltsan
Individual

Email: Zachary.Zeltsan@gmail.com
📦 where this page comes from