Tag: SAML

Identity Broker Service in OpenID Connect: Supporting Multiple Identity Providers & Service Providers

mustnotgrumbleLeave a comment

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

Identity Broker Service in OpenID Connect

In an earlier blog post (Identity Broker Service in SAML) described how to support connections between multiple service provides and multiple identity providers by building an Identity Broker Service. This service presents the user with a list of identity providers supported by the service provider and then forwards a <saml:AuthnRequest> to the appropriate identity provider. The broker then maintains this connection and returns a <saml:Response> from the identity provider back to the service provider. The service provider accepts the <saml:Response> and trusts the end user. In order to build this model using SAML the identity broker service requires development and deployment to the internet and the sharing of keys between all service providers and identity providers.

Using OpenID Connect the same function can be built without the need for an intermediary broker service. This is because in OpenID Connect is designed with the user being able to select their preferred identity provider. The Identity Provider, also known as the OpenID Provider, renders the authentication challenge and gains user approval before sharing user attributes. OpenID Connect performs authentication to log in the End-User or to determine that the End-User is already logged in. OpenID Connect returns the result of the Authentication performed by the Server to the Client in a secure manner so that the Client can rely on it, hence the Client is called Relying Party (RP).

OpenID Connet without Hub

Continue reading “Identity Broker Service in OpenID Connect: Supporting Multiple Identity Providers & Service Providers” →

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