Feb 7
SCIM (System for Cross-domain Identity Management)
ACM.150 Automated management of identities across systems
Part of my series on Automating Cybersecurity Metrics. The Code.
In my last post I provided an overview of how Okta can interact with systems to help with authentication and SSO.
One of the terms I mentioned was SCIM which stands for System for Cross-domain Identity Management. This post covers what SCIM is so we can take a look at how it works in more detail in upcoming posts.
The SCIM standard came into existence as companies started using cloud-based platforms and needed to integrate identity management between different systems. You can read about the history of SCIM here and in the referenced documents.
The SCIM standard attempts to define a standard way to automate the exchange of identity-related information. SCIM builds on prior standards such as SPML, PortableContacts, vCards, and LDAP directory services but attempts to simplify the process.
The standard is defined in the following documents:
RFC 7642- System for Cross-domain Identity Management: Definitions, Overview, Concepts, and Requirements
This document is not a standard but is for informational purposes. It defines some of the basic terminology.
- Triggers: activities that start SCIM flows.
- Actors: The parties involved in transferring identity information.
- Modes: Push or pull identity information.
- Flows: Different scenarios when identity information will be pushed or pulled between actors (e.g. creating, updating, or deleting an identity or changing a password).
- Scenarios when SCIM might be used such as migrating between systems or syncing identities for the purpose of SSO.
RFC 7643 — System for Cross-domain Identity Management: Core Schema
This document defines the JSON schema used by SCIM. For example, this is the most minimal representation of a user (Section 8.1, Figure 3):
{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
"id": "2819c223-7f76-453a-919d-413861904646",
"userName": "bjensen@example.com",
"meta": {
"resourceType": "User",
"created": "2010-01-23T04:56:22Z",
"lastModified": "2011-05-13T04:42:34Z",
"version": "W\/\"3694e05e9dff590\"",
"location":
"https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646"
}
}By defining a standard format for data to be passed between systems, different vendors can write code to handle this standard data format. That means different systems will be more easily integrated. In fact, AWS and Okta integrate using SCIM — but we’ll look more into the details of that in an upcoming post.
The document also defines some key terms which you might see in vendor documentation related to identity management, including Okta’s.
Service Provider: An HTTP web application that provides identity information via the SCIM protocol.
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 service provider.
Provisioning Domain: A provisioning domain is an administrative domain external to the domain of a service provider for legal or technical reasons. For example, a SCIM client in an enterprise (provisioning client) communicates with a SCIM service provider that is owned or controlled by a different legal entity.
Resource Type: A type of a resource that is managed by a service provider. The resource type defines the resource name, endpoint URL, schemas, and other metadata that indicate where a resource is managed and how it is composed, e.g., “User” or “Group”.
Resource: An artifact that is managed by a service provider and that contains one or more attributes, e.g., “User” or “Group”.
Endpoint: An endpoint for a service provider is a defined base path relative to the service provider’s Base URI over which SCIM operations may be performed against SCIM resources. For example, assuming that the service provider’s Base URI is “https://example.com/", “User” resources may be accessed at the “https://example.com/Users" or “https://example.com/v2/Users" endpoint. Service provider schemas MAY be returned from the “/Schemas” endpoint.
RFC 7644 — System for Cross-domain Identity Management: Protocol
The third document defines the protocol for sending requests between systems to query or update identity information. The SCIM protocol uses HTTP to send messages between systems. The protocol makes some recommendations regarding authentication and authorization to perform actions via the SCIM protocol but does not provide any SCIM-specific mechanism.
One key point:
Regardless of methodology, the SCIM service provider MUST be able to map the authenticated client to an access control policy in order to determine the client’s authorization to retrieve and update SCIM resources.
Refer to the specification for details to perform the actions listed below using the defined endpoints in Table 2:
Resource Endpoint [HTTP] Operations Description
-------- ---------------- ---------------------- --------------------
User /Users GET (Section 3.4.1), Retrieve, add,
POST (Section 3.3), modify Users.
PUT (Section 3.5.1),
PATCH (Section 3.5.2),
DELETE (Section 3.6)
Group /Groups GET (Section 3.4.1), Retrieve, add,
POST (Section 3.3), modify Groups.
PUT (Section 3.5.1),
PATCH (Section 3.5.2),
DELETE (Section 3.6)
Self /Me GET, POST, PUT, PATCH, Alias for operations
DELETE (Section 3.11) against a resource
mapped to an
authenticated
subject (e.g.,
User).
Service /ServiceProvider GET (Section 4) Retrieve service
provider Config provider's
config. configuration.
Resource /ResourceTypes GET (Section 4) Retrieve supported
type resource types.
Schema /Schemas GET (Section 4) Retrieve one or more
supported schemas.
Bulk /Bulk POST (Section 3.7) Bulk updates to one
or more resources.
Search [prefix]/.search POST (Section 3.4.3) Search from system
root or within a
resource endpoint
for one or more
resource types using
POST.SCIM — Summary
As you can see from the list above, SCIM facilitates sharing identity and related information between systems. The JSON schema defines the standard for the data sent between systems and the protocol defines how the messages will be sent back and forth.
As noted there are various mechanisms for pushing and pulling data so exactly what triggers a change may differ from system to system. Additionally, it appears here that we are syncing data, so we’ll have to see how that works in relation to truly federating authentication to a third-party system as I set out to do in this post:
Now that we have a rough idea how SCIM works, we can take a closer look at how it works between two specific systems.
Follow for updates.
Teri Radichel | © 2nd Sight Lab 2023
If you liked this story ~ use the links below to show your support. Thanks!
Support:
Clap for this story or refer others to follow me.
Follow on Medium: Teri Radichel
Sign up for Email List: Teri Radichel
Follow on Twitter: @teriradichel
Follow on Mastodon: @teriradichel@infosec.exchange
Follow on Post: @teriradichel
Like on Facebook: 2nd Sight Lab
Buy a Book: Teri Radichel on Amazon
Buy me a coffee: Teri Radichel
Request services via LinkedIn: Teri Radichel or through IANS ResearchAbout:
Slideshare: Presentations by Teri Radichel
Speakerdeck: Presentations by Teri Radichel
Recognition: SANS Difference Makers Award, AWS Hero, IANS Faculty
Certifications: SANS
Education: BA Business, Master of Sofware Engineering, Master of Infosec
How I got into security: Woman in tech
Company (Penetration Tests, Assessments, Training): 2nd Sight LabCybersecurity for Executives in the Age of Cloud on Amazon
Cloud Security Training (virtual now available):
2nd Sight Lab Cloud Security Training
Is your cloud secure?
Hire 2nd Sight Lab for a penetration test or security assessment.
Have a Cybersecurity or Cloud Security Question?
Ask Teri Radichel by scheduling a call with IANS Research.
More by Teri Radichel:
Cybersecurity and Cloud security classes, articles, white papers, presentations, and podcasts
