By: Chris Phillips
Simple Cloud Identity Management, or SCIM for short, made its first foray into the standards process at IETF 83 with a standing room only birds-of-a-feather (BoF) session. Since then SCIM has been working on finalizing its charter, which went to the area directors in late April and has been a topic of interest in numerous identity- and access-management communities, such as the Internet Identity Workshops (IIW), working groups (WGs) of Internet2 and TERENA, the Kantara Initiative, and several advocacy campaigns of SCIM contributors.
What is SCIM?
The SCIM protocol takes a pragmatic approach to the challenge of provisioning user identity across cloud-based service providers. The Simple in Simple Cloud Identity Management is more than just a name; it is a principle participants have used to evolve the concept and hope to continue as it goes through the IETF process to become a formal standard. The SCIM website has a phrase that succinctly sums up the approach: “In essence, make it fast, cheap, and easy to move users in to, out of, and around the cloud.”
Clearly articulating what is in scope for SCIM has been a vigorous exercise of how to strike a balance between complexity, simplicity, and the appropriate level of utility to provisioning identity and identity-related information.
Without broad adoption of a standard way to do user provisioning, services have had to build custom systems. In turn, anyone doing business with that service must bear the cost of using a custom provisioning interface for each service and a custom schema with little re-use along the way. Provisioning within organizations also suffers this same fate.
While there are standards in this space, adoption is low. There is an unexpected scaling challenge in that instead of worrying about whether it can ‘scale up,’ the primary question is whether it can scale to just the right size. An organization may only need a fraction of what other protocols offer and need to operate on the corresponding fraction of resources and infrastructure.
SCIM’s pragmatic approach is attractive as it is designed to be nimble, less burdensome to adopt than other protocols, and it is more cost effective than to write, staff, and maintain a custom provisioning environment.
• the service provider, which holds the identity information being operated on;
• the consumer, which is a website or application using the SCIM protocol to manage identity data maintained by the service provider; and
• resources, which are service provider-managed artifacts containing one or more attributes.
[Figure 1. Key elements of SCIM]
SCIM requests are made via HTTP operations and responses are returned in the body of the HTTP response, formatted as JSON or XML depending on the request, with the request status indicated in both the HTTP status code and the body of the response.
Operations and Expected Actions for HTTP
HTTP Operation Action
GET Retrieves a complete or partial resource.
POST Creates a new resource or bulk modifies resources.
PUT Modifies a resource with a complete, consumer-specified resource (replace).
PATCH Modifies a resource with a set of consumer-specified changes (partial update).
DELETE Deletes a resource.
Resources with Respective Endpoints
|User||/Users||GET, POST, PUT, PATCH, DELETE||Retrieve/Add/Modify users|
|Group||/Groups||GET, POST, PUT, PATCH, DELETE||Retrieve/Add/Modify groups|
|Service Provider Configuration||/ServiceProviderConfigs||GET||Retrieve the service provider’s configuration|
|Schema||/Schemas||GET||Retrieve a resource’s schema|
|Bulk||/Bulk||POST||Bulk modify resources|
Full details of the protocol responses can be found on the SCIM website3.
The SCIM schema was inspired by the approach to schema taken by Portable Contacts4, along with some extra elements from initial participants. The Portable Contacts model offers more flexibility than other formats to capture data complexity, which translates into the ability to capture complex data relationships at a user level. In keeping with the spirit of simple, the core schema for SCIM is intended to meet 80 percent of a user’s basic attributes and allow implementers to get up and running as quickly and easily as possible. If mappings between the identity set being used and SCIM do not exist, extensions are available to tailor the schema. SCIM endpoints can be interrogated for schema much like Lightweight Directory Access Protocol (LDAP) servers so schema customizations are discoverable.
A side effect of this schema style is that SCIM can encapsulate more detail about an identity than LDAP’s inet-OrgPerson or a Security Assertion Markup Language (SAML) profile. The approach to address this is to have recommendations for LDAP and SAML mappings that will provide guidance on how to take a high-fidelity SCIM schema and transform it to a lower-fidelity format. The intended outcome of the mappings is to make it easier for implementers and to help foster consistency for those who need mappings. Other mappings maybe published depending on the demand for them.
SCIM, Schema, and Scope
Schema has been one of the most frequentlydiscussed items on both the SCIM and IETF lists with topics like:
• should attribute values be constrained based on other attribute values?
• should applying certain access control methodologies using certain attributes be expected or required? and,
• what is expected of SCIM regarding management of unique identifiers?
Each question is interesting on its own as an identity-management topic. That said, SCIM’s guiding principle of simplicity suggests that those requirements should be overlaid/profiled atop the specification to meet the demands of each unique use case. Constraining SCIM to a minimal standard schema with a flexible information model, combined with structured data transport, has broader utility and encourages adoption. At the same time, there is opportunity to leverage SCIM as the lower-level building block for those advanced uses and focus on the application of policy and delegate transport of the data to SCIM.
Specification interoperability sessions are held where possible to exercise implementations and gain running code experience. Three have been held so far with the second held in Paris just before IETF 835 with a total of nine participants. The face-to-face sessions have been invaluable for identifying gaps or ambiguities that need to be clarified. The most recent was held at an Internet Identity Workshop from 1–3 May in Mountain View, California, U.S.A.6 There were nine participants, some of whom have SCIM implementations in production.
The Road Ahead
SCIM has been at the 1.0 state since December 2011 as a result of strong community participation. Vendors have been running code for months and a number have SCIM as features in their products7 collecting valuable real-world experience living with the technology and going through their product lifecycle with it. Others have stayed on the sidelines, either to see if the protocol gains more traction or because they are not comfortable with the uncertainty surrounding a new protocol and are waiting to see what will happen with SCIM and the IETF.
Draft charter milestones have been proposed to adopt the SCIM core schema, RESTful interface definition, and use cases as a living document by the end of summer 2012 and by summer 2013 to have formalized SAML bindings and LDAP mappings. This fills some gaps for those who may have been waiting to see what will happen and provides guidance on other areas of the protocol.
The SCIM WG has a number of topics vying for attention that we will introduce here as a glimpse into future discussions.
Defining and Recommending Possible Topologies
Describing possible deployment topologies will help identify where and how SCIM could be applied as a way to encourage adoption. The word cloud in SCIM is a bit of a misnomer and shouldn’t preclude SCIM from being deployed internally. Internal deployments may be more compelling than connecting to a Software as a Service (SAAS) vendor. There is more customization and more ownership of provisioning processes internally and hence equal if not more utility in deploying SCIM to simplify the internal provisioning environment and consolidate to a common model with SCIM as a foundation element.
Detailing End-Point Security Approaches
The challenge is that one size does not fit all and not all sites are equally equipped to execute one model over another. SCIM requires TLS 1.2 to be used and recommends OAuth Bearer Token as a method to encourage interoperability between SCIM endpoints, but remains flexible to allow other protocols to be used.
One of the bindings being examined with the SCIM protocol is SAML and how it could and should interact with SCIM. From a security perspective, SAML offers SCIM a trust model through SAML federations (private or public) and raises other interesting security conversations. Should all endpoints within a trust set be equally trusted?, is just one of many questions in this space. It is likely SAML environments would benefit from the option to augment their experience with formalization around provisioning to SAML end points.
There are a number of discussion points that could appear under the schema heading. Some have been mentioned already but not the more subtle and slippery slope of a ‘just one more thing’ approach to schema additions. This is manifested by the appearance of more and more attributes outside the core schema until there are more attributes appearing in the extension than in the core. SCIM is flexible enough to allow this, but should this pattern be encouraged, discouraged, or not something to be concerned about? Is this the antipattern of fortifying t
he core attribute model? It may very well be an acceptable way to use SCIM if it simplifies the entire infrastructure or is a technique to keep the schema evergreen and allow for maximum flexibility as the years go by. It will be an interesting discussion to dig into.
This brief tour of provisioning topics highlights only some of the areas to be explored. As SCIM heads into the next round of improvements, keeping the balance between simplicity, practicality, and flexibility—even though they may be at odds with each other —will improve the durability of SCIM as a tool in the middleware toolkit. If these topics strike a chord with you, or if you have thoughts and would like to contribute, please join in by trying SCIM8 and joining the mailing list at firstname.lastname@example.org.
1. A lightweight text-based open standard designed for human-readable data interchange
It was standing-room-only at the Simple Cloud Identity Management birds-of-a-feather session.
The System for Cross-domain Identity Management (scim) working group was chartered by the IESG on 21 June, 2012, in the Applications Area of the IETF. The agreed charter of the working group, including goals and milestones, is available at http://datatracker.ietf.org/wg/scim/charter/.