Tag: SAML 2.0

Identity Broker Service in SAML: Supporting Multiple Identity Providers & Service Providers

mustnotgrumble1 Comment

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

Identity Broker Service in SAML

A federated organisation may have multiple distinct services (service providers) where each service is protected under a distinct trust domain. The same organisation may wish to trust multiple external & internal identity providers and allow the end user to select their preferred identity provider. Furthermore the same federated organisation may require greater levels of certainty for specific services and may wish to limit the available identity providers for a specific service or enforce step-up authentication on the identity provider. This pattern is useful for governments and enterprise’s wishing to move away from a Push Model for Enterprise Identity Architecture.

In order to support multiple services and multiple identity providers and possible multiple rules an Authentication Broker Service is required. This model is often known as either a Hub Service or Chained Federation. The following sequence diagram explains how the pattern would working using <saml:AuthnRequest> (SAML 2.0) and <saml:Response> between four parties (User Agent, Service Provider, Authentication Broker Service and Identity Provider):

SAML Hub Service

 

  1. The User Agent access a specific Service (There can be N+ service providers depending on the organisation)
  2. The Service Provider sends a <saml:AuthnRequest> to the registered Authentication Broker Service (limitation that an SP must be mapped to one Broker)
  3. The Authentication Broker Service holds a list of Identity Providers trusted by the Service Provider and returns this list to the User Agent
  4. The User Agent selects their preferred Identity Provider provided as a list by the Broker
  5. The Broker service generates a new <saml:AuthnRequest> which it forward to the selected Identity Provider
  6. The Identity Provider challenges the user agent
  7. The Identity Provider authenticates the user agent
  8. The IdP returns the <saml:Response> to the Broker for the authenticated principal
  9. The Broker returns the <saml:Response> to the Service Provider (which may choose to match against any mapped identity)
  10. The Service Provider grants access to the User Agent

Note a slightly different pattern would be to pass a reference to a SAML artefact between the Broker and the SP. This would use the <saml:ArtifactResolve> element in the message passed back from the Identity Provider. This pattern would require a direct service between the SP and the IdP to resolve the attributes in the artefact. This pattern extension is only recommended when the authentication request can be deferred when multiple profile attributes are required from the identity provider.

Example: UK Government Identity Assurance Hub Service SAML 2.0 implementing the OASIS SAML V2.0 Identity Assurance Profile

Nomenclature: Terminology differences between OpenID Connect & SAML

Comparison of OpenID Connect with OAuth2.0 & SAML2.0

mustnotgrumbleLeave a comment

The following is a high level feature comparison between OpenID Connect 1.0, OAuth 2.0 & SAML 2.0

  • OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
  • OAuth 2.0 focuses on client developer simplicity while providing specific authorisation flows for web applications, desktop applications, mobile phones, and living room device
  • SAML 2.0 provides a standard for exchanging authentication and authorisation data between security domains using an XML-based protocol which uses security tokens containing assertions to pass information about a principal between an identity provider and a service provider.

Usage:

  • OpenID Connect allows a user to authenticate to an on-device App, a service or a site using an identity established with an Identity Provider (IdP).
  • Integration of OAuth 1.0 and OpenID 2.0 required an extension. In OpenID Connect this OAuth 2.0 capability is built into the protocol itself.
  • Mobile apps don’t have access to the HTTP POST body which is required in SAML to post the token back to the Service Provider. As such SAML 2.0 has a native app (yes you could use a blended app) limitation

APIs:

  • All three have extensive libraries (OAuth libraries, OpenID Connect libraries, simple SAML PHP library)
  • OpenID Connect is REST based encapsulating JSON Web Tokens while SAML is XML based
  • OpenID Connect performs many of the same tasks OpenID 2.0, OAuth2.0 and SAML, but does so in a way that is standardised and API-friendly.
  • OpenID Connect can also be extended to include more robust mechanisms for signing and encryption

Tokens (Signing & Encryption):

  • OpenID Connect is REST based encapsulating JSON Web Tokens which do not only sign the payload (does not encrypt it)
  • SAML is XML based and supports signing & encrypted certificates
  • OAuth 2.0 uses bearer token (similar to cookies) which do not require a bearer to prove possession of cryptographic key material (proof-of-possession). Risks for the enterprise.

Feature Comparison:

OpenID Connect 1.0:

  • ✔ SP & IdP Initiated Login
  • ✔ High Security Identity tokens (JSON Web Token)
  • ✔ Collects user’s consent before sharing attributes
  • ✔ Token contains user identity information
  • ✔ Distributed & Aggregated Claims
  • ✔ Dynamic Introductions (client discovery & on-boarding)
  • ✔ Session Timeout (future)

OAuth 2.0:

  • ✔ SP & IdP Initiated Login
  • ✘ High Security Identity tokens (uses bearer token which have no proof of possession)
  • ✔ Collects user’s consent
  • ✘ Token contains user identity information
  • ✘ No Distributed & Aggregated Claims
  • ✘ No Dynamic Introductions (client discovery & on-boarding)
  • ✘ No Session Timeout

SAML 2.0:

  • ✔ SP & IdP Initiated Login
  • ✘ Does not support embedded applications
  • ✔ High Security Identity tokens (e.g. X.509)
  • ✘ Not Responsible for collecting user’s consent
  • ✘ Token contains user identity information
  • ✘ No Distributed & Aggregated Claims
  • ✘ No Dynamic Introductions (client discovery & on-boarding)
  • ✘ No Session Timeout