Monday Sep 28, 2015

Standards Corner: The IETF Publishes SCIM V2

Last Friday, the IETF published SCIM v2 as RFC7643 (SCIM Core Schema) and RFC7644 (SCIM Protocol) as well as SCIM’s Use Cases as RFC7642. As editor I want to pass along my thanks to my co-authors:  Morteza Ansari, Kelly Grizzle, Chuck Mortimore, and Erik Wahlstrom and to Kepend Li, editor of the SCIM use case document (RFC7642). I also want to thank the members and the chairs of the SCIM WG as well as the many developers over the past few years who provided valuable feedback to the specifications.

For those that aren’t already familiar with SCIM, it is a new RESTful HTTP protocol that promises to make provisioning and management of User accounts in applications and cloud providers dramatically easier. Instead of older more complex protocols like LDAP and X.500, or writing many different proprietary connectors, developers can now depend on an easy to implement RESTful protocol.

SCIM V1 began as an Open Web Foundation initiative in 2010 by Salesforce, PingIdentity, Sailpoint, UnboundID, and Nexus Technology as a way to provision users to cloud service providers. Kelly Grizzle of Sailpoint, one of the original SCIM spec co-authors and co-author for SCIMv2, put it this way in his CIS2014 presentation: "SCIM, Why It’s More Important and More Simple, Than you Think":

"SCIM was founded about [five] years ago at [CIS] in 2010. We needed a identity management protocol. A standard potocol. There’s a bunch of different protocols out there and we wanted a standard one….In May 2011, we really kicked off work under Open Web Foundation. A loose standards body to get a spec launched and off the ground. In Dec 2011, we came out with a 1.0 spec."

While SCIM v1 was a great start, there was more work to do. For example, it was not clear how implementers could define new attributes and extend SCIM.  Could SCIM be used for any identity information and not just Users? What is the schema model? How should clients and service providers negotiate the inevitable difference in the attributes they need and use about users? Did service providers have to accept data exactly as provided? If a client asked a service provider to delete a user resource, was the service provider obligated to do so? If a user is deleted and they come back, can they regain their old profile?  What should happen when a client tries to update a read-only attribute? SCIM V2 addresses all of these issues.

SCIM V2's low-friction approach makes provisioning easy to implement and use. At the recent Cloud Identity Summit last summer, Ian Glazer of Salesforce spoke about how the new Identity standards, including SCIM, are about to have their TCP/IP moment in history:

"Standards for federated single sign-on and attribute distribution are especially strong. Historically user provisioning has not been great but it is about to get much better with SCIM 2.0. Authorization, in the form of XACML and its related profiles, is robust and capable and its adoption curve ought to be bending upwards." 

Here is a summary of some of the new features of SCIM V2:

1. SCIMv2 Has an Extensible, Robust Schema Model

It is fitting that Ian Glazer’s talk, was titled is Identity having its TCP/IP moment. As TCP/IP became a major influence in the design of SCIM v2. By that I mean the working group, in its desire to keep things “simple”, adopted a “robust” philosophy first proposed by Jon Postel in the development of TCP/IP

"TCP implementations should follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others."

For SCIM, rather then designing a schema system that throws errors for every non-conformance (for example as is done with XML Schema), the working group decided to have a flexible set of processing rules defined by a set of attribute characteristics. SCIM service providers are free to ignore what they do not understand or do not care about. A SCIM request fails only when something is known to be wrong. In another example, a SCIM request that attempts to update an attribute that the service provider has declared as readOnly may still succeed since the attribute modification is simply ignored. This may seem trivial, but it allows for clients to do simple things like use HTTP “GET” to retrieve a resource and then perform an HTTP “PUT” to put the resource back after changing one or more attributes. Rather then rejecting the request, the SCIM service provider simply picks out what changes are relevant and processes the request.

For more information on robust schema, see my post: A Robust Schema Model for SCIM

2. Focus on JSON      

Support for XML was dropped early in the process. This was in part due to the declining interest inXML. But I think this also enabled a change in philosophy about schema enforcement (see #1) and the desire to keep SCIM simple. 

3. Resource Types

SCIM V2 now allows service providers to offer new resources beyond just Users and Groups.  To define this, SCIM V2 has a new endpoint called “/ResourceTypes” listing the types of resources that are supported by a service provider. Each SCIM ResourceType defines the main SCIM “schema” uri, any extension schemas (e.g. like an enterprise user), and the actual endpoint where the resource is located.  For example, the resource type for “User” is defined:

    "schemas": ["urn:ietf:params:scim:schemas:core:2.0:ResourceType"],
    "id": "User",
    "name": "User",
    "endpoint": "/Users",
    "description": "User Account",
    "schema": "urn:ietf:params:scim:schemas:core:2.0:User",
    "schemaExtensions": [
       "required": true

Resource types make it possible to define new objects and clarifies how SCIM schema can be extended in the future. Of course, while service providers are free to invent their own, the SCIM WG may specify new schemas and resource types for new resources where interoperability is needed.

 4. New PATCH Method

SCIM has a new PATCH command that is now based on RFC6902 known as “JSON Patch” by Paul Bryan and Mark Nottingham.  In the SCIM version, a new filter syntax (which is the same as a SCIM query filer) may be used to select specific records of multi-valued complex attributes. This gives clients the ability to update specific sub-attribues of attributes like “addresses” (e.g. update a street name). It also improves modification of large multi-value attributes like group “members”.

5. Clarifications on Authentication and Security

Many reading the SCIMv1 specification wondered how SCIM does a “bind” operation (coming from LDAP). The specification now clarifies that SCIM is just a normal HTTP service and as such, uses all of the HTTP standard authentication schemes including OAuth. While SCIM doesn’t itself do “authentication”, SCIM servers may be used by authentication systems to retrieve credential information and match password values as part of authentication service architecture.

6. Search

One ongoing concern that some adopters had with SCIMv1.1 was that supported searching only via HTTP GET. Since SCIM’s primary objective is the provisioning of personal information, it was concerning to expose personal information in URLs as part of a GET request. Section 9.4 of HTTP RFC7231 tells more about the story:

9.4. Disclosure of Sensitive Information in URIs

URIs are intended to be shared, not secured, even when they identify secure resources. URIs are often shown on displays, added to templates when a page is printed, and stored in a variety of unprotected bookmark lists. It is therefore unwise to include information within a URI that is sensitive, personally identifiable, or a risk to disclose. Authors of services ought to avoid GET-based forms for the submission of sensitive data because that data will be placed in the request-target. Many existing servers, proxies, and user agents log or display the request-target in places where it might be visible to third parties. Such services ought to use POST-based form submission instead. Since the Referer header field tells a target site about the context that resulted in a request, it has the potential to reveal information about the user's immediate browsing history and any personal information that might be found in the referring resource's URI. Limitations on the Referer header field are described in 
   Section 5.5.2 to address some of its security considerations.  

To address this concern, SCIM v2 supports searching by using the HTTP POST method and a  “/.search” at the end of a SCIM URI to indicate the client is performing a search request instead of creating a new resource. Further, because a “/.search” can be applied anywhere, SCIM can now support a search request against a specific resource type endpoint (e.g. /Users), or the entire server (from the root). 

For more information about SCIM, see the SCIM web page where you'll find an overview, a list of implementations and links to the specifications.  

Tuesday Dec 16, 2014

Standards Corner: IETF SCIM Working Group Reaches Consensus

Today in the Standards Corner, Phil Hunt blogs about the recent consensus call for SCIM (System for Cross-domain Identity Management). What is new about it? Why SCIM in relation to LDAP?[Read More]

Wednesday Jun 18, 2014

Standards Corner: IETF Revisits HTTP/1.1

HTTP has been one of the most successful IETF specifications aside from the Internet itself. When it was created in 1999, the authors of HTTP had no idea how big and how widely used it would be.  For many years the focus was on the evolving world-wide-web and HTML. The web itself went through many transformations with the introduction of Ajax and then HTML5 by the W3C.  Meanwhile, non-browser use of HTTP has been steadily growing especially with the exploding popularity of smart devices, the Internet of Things, and in particular RESTful APIs.

Last week, the IETF officially did away with RFC2616, the main specification document that defined HTTP/1.1. RFC2616 has been broken up into 6 specifications, RFC7230 through 7235.

[Read More]

Get the latest on all things Middleware. Join Oracle's Middleware Community today.

Find Us on facebook Follow us on twitter Catch Us on YouTube 


« November 2015