Will the up and coming OpenID Connect (OIDC) displace the established Security Assertion Markup Language (SAML)? In some domains, it already has, thanks to the wide availability of implementations for many programming languages. It also offers an easy solution for delegating access to protected resources, something that is possible with SAML but more difficult to realise, and is a typical use case for mobile applications today. However, OIDC has no concept of a “federation”, i.e. a private group of entities who trust each other, and that is a big drawback to adoption in a federated context like research and education. In this article, we will look into a few initiatives that seek to bridge the gap between the two realms.

OpenID Connect is a protocol that adds a “simple identity layer” on top of another protocol, OAuth 2.0. Although fairly new — OpenID Connect 1.0 was finalised early 2014 — it is already widely used on the web, most noticeably by social networks who offer to identify their users for other web sites. Explaining those protocols goes way beyond the scope of this article, so let’s sum it up this way:

The identity layer that OIDC brings consists of information about the authenticated user provided to the application that asked the user to identify herself in the first place (“application” is used here to designate any kind of web, mobile or native application).

Does that sound an awful lot like SAML attributes? Well, yes only they are written in JSON instead of XML. Sidestepping the obvious and inflammatory “Why reinvent the wheel?” question (answer: because some people just cannot stand XML), let’s look into how the OIDC and SAML worlds could be connected.

Shibboleth speaks JSON

First, the one which has some code, something tangible that you can run. Your Shibboleth Identity Provider is happily providing user attributes today. Wouldn’t it be nice if it could also provide the same attributes, but over a different protocol? Then there would be no need to operate another service to support OIDC, which would mostly duplicate what the IdP does anyway (authenticating users, fetching attributes from storage, filtering and releasing them).

This is what the University of Chicago together with Unicon set out to do: adding support for OIDC to the Shibboleth IdP. The whole project is open on GitHub and we successfully tested it in a proof of concept installation with a simple test web application. Of course this is work in progress thus does not do everything you would wish, but a majority of the protocol is already implemented so it is worth a try. Hopefully, this project will be integrated into the IdP code one day, though we do not expect it to happen soon. The Shibboleth Consortium has not yet declared a stance on OpenID Connect so it might go either way.

Attributes meet claims

The OIDC specification defines a standard set of claims about the user, what SAML calls attributes. Unfortunately, this set is heavily inspired by the social web and therefore ill-suited for the research & education community. For example, it lacks any notion of affiliation to an institution or group, or has very culturally-dependent claims like “middle name”. There is a mismatch here between the well-known eduPerson schema and the standard OIDC claims and so far no common way of dealing with this difference exists.

That’s why people are scratching their heads to bring the two together: the OpenID Connect for Research and Education Working Group (under REFEDS) started the effort by drafting a specification for conveying eduPerson and SCHAC attributes as claims. Their work is currently published in a wiki and on GitHub. Not waiting for standardisation, some implementers are already shipping eduPerson attributes with OIDC: the Australian Access Federation added them to their AAF Rapid Connect service in a special claim of their creation. This non-interoperable solution may work in a single federation but is unlikely to reach acceptance outside of it.

Trust and federations

In the OIDC world, trust between OpenID providers and relying parties (i.e. clients, applications which receive claims) must be established bilaterally, either statically or dynamically. There is no notion of a group of entities that would trust every member of the group, what we call a federation in this context.

Manually vetting and registering every possible client would quickly turn into an administrative nightmare for an OIDC provider operator, so dynamic client registration was defined to allow clients to automatically register themselves at a provider. Unfortunately, it means a provider will trust any client that asks and provide it with user information. Even though user consent is still required to release personal information, trust is established before the provider’s operator has a chance to review this agreement and personal user information may already be given away. Such wanton distribution of personal information is unacceptable in our context.

Moreover, SAML has a solid solution to this problem: metadata describing all participants of a federation, verified and cryptographically signed by the federation operator. In this domain, OIDC must catch up to compete and Roland Hedberg is actively presenting his solution to bring federations to OIDC, but again, this is work in progress and not standardised yet.

Wait and see

So is SAML obsolete yet? Absolutely not! It continues to provide seamless single sign-on on the web with good security and privacy controls. OIDC is catching up, but until it reaches the same level as SAML in areas mentioned, it will not replace it. We can, however, envision running the two protocols side by side in the meantime, in order to provide easier integration for developers who are new to SAML and expect OIDC to be available everywhere.

Much of the work cited in this article happens in working groups and mailing lists, even though they are often public and open for participation, progress is a bit hard to track unless they have a code repository. We will continue to monitor those projects and report back if a breakthrough happens.