Why the Future of Identity is OpenID Connect and not SAML

This blog is part of a series comparing the implementation of identity management patterns in SAML and OpenID Connect:

Future of Identity Federation is OpenID Connect

Identity management is an enabler for networked services whether web browser, mobile or smart-tv applications or the internet of things. The increase in services will create an increase in passwords without mechanism for sharing & trusting identities. eGovernment services require a higher level of identity verification than the social authentication capabilities of Twitter & Facebook connect. The future of eGovernment Identity is an interoperable authentication and authorisation capability that can support higher levels of identity verification.

The importance of interoperability amongst identity solutions is that it will enable individuals to choose between and manage multiple different interoperable credentials. Futhermore service providers will choose to accept a variety of credential and identification media types. “Identity Solutions will be Interoperable” is a guiding principle of the US National Strategy for Trusted Identities in Cyberspace (NSTIC) which is a White House initiative for both public & private sectors to improve the privacy, security, and convenience of online transactions.

SAML is insufficiently interoperable to be the future standard for identity management federation. SAML is limited in its ability to support mobile & smart-TV applications and requires the implementation of a complex Broker Service in order to support multi-service provider & multi-IdP use cases.

OpenID Connect will most likely supersede SAML for all eGovernment externalised identity management. OpenID Connect is a lightweight identity verification protocol built on top of modern web standards (OAuth 2.0, REST and JSON) superseding OpenID 2.0. OpenID Connect allows a service provider (Relying Party) to select between a variety of registered or discovered identity providers. OpenID Connect can satisfy all of the SAML use cases but with a simpler, JSON/REST based protocol.

SAML OpenID Connect Comparison
SAML 2.0 & OpenID Connect comparison

Limitation of a SAML Hub Service:

Because a Hub Service is required to mediate between multiple identity providers & attribute providers the hub service is required to ensure that privacy of the principal is maintained across providers. “In order to ensure uniqueness of the persistent identifier and to ensure no identifiers are stored within the hub service, an algorithm will be used for generation of the persistent identifier. This will be implemented within every attribute provider and service provider (within the service provider matching service).”

Furthermore as eGovernment underlying business service enablement will move away from web based forms or web enabled kiosks in government offices an identity and security system will be needed that can support multiple channels. The limitation of SAML to only support WebSSO will quickly inhibit the progress to support a mobile app, smart TVs or eUICC enabled service. It is therefore likely that the future of eGovernment services will be to support the standards used by in excess of 1Billion users and extension to SIM cards (GSMA Mobile Connect),

A SAML Hub Service Example: UK Government Identity Assurance Programme
The UK Government’s Identity Assurance Programme (IDAP) is developing “a better, safer and reusable way to prove you are who you say you are when using government services online”. A number of certified identity providers have been selected to verify individuals identity. Integrated UK Government services act as service provider trusting the identities provided by the certified identity provider. This interaction is built following a Hub Model which requires the build & deployment of a trusted broker service to manage SAML interoperability.

The UK Government’s Identity Assurance Hub Service SAML 2.0 Profile implements the standard SAML Assurance Profile and specifies the responsibilities for identity providers and attribute providers. The IDAP service specification was published before OpenID Connect’s ratification. The two principle vendors involved as contributors to IDAP document were Oracle and Microsoft. As of July 2014 neither vendors principle identity products support OpenID Connect.

The Identity Assurance Hub Service SAML 2.0 Profile specification defines a profile for the use of SAML assertions and request-response messages to be used between participants in the Identity Assurance federation architecture. The UK Gov IDAP hub service profile is defined to support federated authentication to government services and the future support of single sign-on (SSO).

The requirement of an identity assurance service is that it allows the user to securely select their preferred identity provider with a trust relationship between the IdP and the SP that disallows impersonation. “Being able to prove your identity online easily, quickly and safely is recognised as a key enabler of internet use by the government and its users.

The UK Government’s IDAP has a requirement for higher levels of authorisation which require the Hub Service to be able to fetch data from different attribute providers. For each query a unique <AttributeQuery> request is sent from the Hub Service to the Attribute Provider to support the attribute enrichment requirements. This necessitates logic within the Hub Service to determine which attribute providers to use in order to build a unified authorisation profile. In OpenID Connect this capability can be delivered from the Relying Party where varying levels of Authorisation Policy are supported using JSON Web Token optional Authentication Context Class Reference (acr) attribute.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s