Posts Tagged ‘REST’

SCIM – System for Cross-domain Identity Management

2015/05/15

SAML, OAuth, and OpenID Connect, as we have seen, all require the registration of the Client Applications, the Resource Owners (End Users), and the Resource Servers. The Authorization Server (AS) = The OpenID Provider (OP) is thus forced to keep the registration data, perhaps stored in tables. While these standards loosely define what goes into these tables, they do not define either how they are collected nor how these data are managed. SCIM, the System for Cross-domain Identity Management [not to be confused with SCIM the Smart Common Input Method platform] is an attempt to do this. See Ping Identity’s history in their SCIM white paper and a brief Wikipedia article for descriptions of some early attempts. The IETF lists some current draft specs.

The “C” in SCIM used to stand for “cloud”, but on-premises use of SCIM for internal identity management is popular as well. A SCIM server can be in the cloud and still manage on-premises applications using a secure SCIM channel through the firewall. This becomes a “cloud identity bridge”.

In my earlier IAM posts, I noted that the IdP or the AS had table descriptions for Clients, Resource Providers, Resource Owners, etc. This is the beginning of a Schema for SCIM. It needs groups, roles, entitlements, devices.

OpenID Connect

2015/05/01

OpenID Connect allows Client Applications to verify the identity of the End User based on the authentication performed by an Authorization Server. It also allows the Client to obtain basic profile information about the End User.

There are a number of versions of how OpenID Connect was born, e.g. here, here, here, and officially here. I like the story that after multiple influential companies implemented SAML, WS*, and OpenID 2.0, and also Facebook implemented Facebook Connect, Eran Hammer and David Recordon put forth a one page proposal for what became OpenID Connect. I can’t find this historical one-pager, and even the core spec today is around 100 pages with half a dozen other supporting documents. Some have called it a functional merger of OpenID and Facebook Connect that is layered on OAuth 2.0. Others provide the “formula”:

(Identity, Authentication) + OAuth 2.0 = OpenID Connect

Whoever should be getting historical credit, the basic idea is both simple and brilliant: Take the authorization mechanism of OAuth 2.0, make a couple tiny additions, which I’ll explain in a moment, and viola, we’ve got a authentication mechanism.

As with OAuth 2.0, there is a registration process that is not specified, but it is essentially the same as for OAuth and is described in the spec under OpenID Connect Discovery and under OpenID Connect Dynamic Client Registration. There is a bit of a pas de deux on terminology. What OAuth calls the Authorization Server AS is also referred to as the OP for OpenID Provider, and OP has an Authorization Endpoint and a Token Endpoint. The client obtains these endpoints during registration.

The fundamental new idea is simply to add a new scope value openid to the initial authorization request message (described in my last post on OAuth 2.0) to the Authorization Server AS. Having openid as one of the scope values, makes requests not only for access tokens but also for a new “identity token” and also opens up the possibility to request more information about the end user. Here are some of these request parameters:

  • scope: must contain the new value openid and may contain one or more of the scope values of profile, email, address, phone, and offline_access
  • response_type: code – means both access and id tokens be returned from the token endpoint in exchange for the code value obtained from the AS
  • client_id: obtained during registration at the AS
  • redirect_uri: one of the pre-registered redirection URI values for the client

This request asks the AS to authenticate the owner/operator of the browser that is sending the message and to return an id_token as well as access_tokens. The id_token will affirm that the user has authenticated recently. The id_token may contain additional claims or information about the user. The method of authentication is not defined by the spec. The id_token includes a JSON object that includes:

  • iss = issuer identifier for the issuer of the response
  • sub = subject identifier, a locally unique within the issuer for the end-user
  • aud = audience(s) for whom this id_token is intended = array of case sensitive strings or a single such string
  • UserInfo Endpoint
  • iat = Issue timestamp
  • exp = Expiration datetime
  • auth_time = time end-user last authenticated
  • How the user was authenticated (optional)
  • many other optional tags

The user runs a protected application which may make additional GET requests to the UserInfo endpoint for REST APIs for identity attributes. Curiously the spec warns that these claims may not be for the end user (due perhaps to man-in-the-middle attacks)! In addition there are language dependencies on the claim values.

The final OpenID Connect specification is dated Feb 26, 2014; and the certification program was launched April 22, 2015 with Google, Microsoft, Ping Identify, ForgeRock, Nomura Research Institute, and PayPal the first to self-certify.

Multiple companies, in support of OpenID Connect, have announced they will no longer be supporting OpenID 2.0 at some point in the near future.

My next IAM post is about SCIM.  It is here.

Introduction to OAuth 2.0, OpenID Connect, and SCIM

2015/04/16

The development of SAML dates from January 2001. As discussed in an earlier post, SAML 2.0 provides a Single Sign On (SSO) authentication and authorization protocol that many view as applicable primarily for federations of enterprises. Mobile applications and dominant Internet applications such as Salesforce, Facebook, Google Apps, Linked In, etc. were providing more or less independent and light-weight “micro-services” fronted by APIs. SAML was deemed too heavy-weight to be supported by such APIs.

By 2014, authentication, authorization, and delegation (of authorized rights) for APIs, are embodied in the standards OAuth, OpenID Connect, and SCIM. These standards call for authentication and access tokens encoded in JavaScript-like Object Notation JSON rather than SAML’s (somewhat more verbose) XML. These JSON tokens are then passed in HTTP headers.

OAuth 2.0 has evolved to be a base technology for authorization, but it’s hard to do authorization without knowing to whom or to what you’re giving rights, and thus authentication sneaks in to the standard. To better address this, OpenID Connect has evolved from earlier versions of OpenID and other security work done by vendors to become a layer on top of OAuth 2.0 for authentication. It would seem that these two standards should merge.

While the proponents of OAuth and OpenID Connect predict that they will eventually supersede SAML, this doesn’t seem likely in the near future as SAML seems to do quite well for enterprises with existing relationships such as supply chains and portals. In addition, there are some use cases where the co-existence of SAML, OAuth, and OpenID Connect seems natural in spite of some duplication of functionality.

Finally SCIM, the System for Cross-domain Identity Management, addresses cross-domain identity management and specifically provides REST APIs for provisioning, change, and de-provisioning, all of which lie outside the realm of OAuth and SAML. SCIM adds considerable complexity to identity management systems, and I’m a little nervous that the initial implementations will have security problems. On the other hand, neglecting these functions is probably worse for security.

My next few IAM posts will discuss the latest versions for each of OAuth, OpenID Connect, and SCIM. I’ll also work an example of co-existence with SAML. The OAuth 2.0 post is next. It is here.