Identity provider discovery and authentication - is SAML the right solution

Question

I’ve done a few OpenID integrations, so I understand the problem I’m about to describe is something OpenID and OAuth can solve, but I’m new to SAML and trying to wrap my head around one particular use case:

So, say user visits Site1, which asks the user to confirm which one of the other sites he or she belongs to (Site2, Site3 etc.)

Site1 cannot authenticate user and relies on Site2 or Site3 to do authentication, so it presents user a list of sites to authenticate against.

User chooses either Site2 or Site3, performs authentication there and is redirected back to Site1. Site1 acknowledges the user and it now knows where the user is from.

Question: Is this a valid problem for SAML to solve?

Answer 1

There are two problems in your question:

1. Service provider (Site1) needs to redirect the user to the identity provider (Site2, Site3, ...) that "owns" the user identity (can authenticate them)

2. Authentication at the identity provider and propagation of this fact back to the service provider

SAML can solve both of these but read on for caveats:

1. One of the profiles in SAML is an Identity Provider Discovery profile. Its definition from the spec (section 4.3):

...a profile by which a service provider can discover which identity providers a principal is using with the Web Browser SSO profile. In deployments having more than one identity provider, service providers need a means to discover which identity provider(s) a principal uses. The discovery profile relies on a cookie that is written in a domain that is common between identity providers and service providers in a deployment. The domain that the deployment predetermines is known as the common domain in this profile, and the cookie containing the list of identity providers is known as the common domain cookie.

As you can see, this profile relies on a common domain cookie that is issued by a discovery service hosted on a common (shared) domain:

When a service provider needs to discover which identity providers a principal uses, it invokes an exchange designed to present the common domain cookie to the service provider after it is read by an HTTP server in the common domain.

The common domain (and associated cookie) requirements were an early take and some developers didn't think it was an elegant approach that met everyone's needs. This lead to the profile being revised and later issued as a separate specification called Identity Provider Discovery Service Protocol and Profile. From this spec:

This specification defines a browser-based protocol by which a centralized discovery service can provide a requesting service provider with the unique identifier of an identity provider that can authenticate a principal. The profile for discovery defined in section 4.3 of [SAML2Prof] is similar, but has different deployment properties, such as the requirement for a shared domain. Instead, this profile relies on a normative, redirect-based wire protocol that allows for independent implementation and deployment of the service provider and discovery service components, a model that has proven useful in some large-scale deployments in which managing common domain membership may be impractical

The mention of large-scale deployments is important. The first attempt (cookie-based profile) was simple but messy; the improved spec does everything the "SAML way"...and greatly increases the complexity of the implementation. It's only worth it if your collection of identity providers is sizable, like all universities in your country for example.

There are many non-SAML options for solving the identity provider discovery problem. The simplest option is "ask the user" by employing a UX-friendly technique for the user to select their identity provider. This blog does a good job of summarizing these options. For a real-world, complex solution to this problem take a look at Swiss universities' implementation.

2. This is a common scenario where SAML is a good fit. Take a look at SAML Technical Overview for more details.

Note: oAuth does not authenticate the user, it authenticates the client app. OpenID Connect is based on oAuth and it can authenticate the user via the id token. The id token and the associated exchange was heavily influenced by SAML

Answer 2

IDP's handle this via Home Realm Discovery.

If an IDP is configured with Sites 1, 2 and 3 then when the application redirects to the IDP, there will be an HRD screen asking the user to pick one of the three.

The user selects one, authenticates and is redirected through the IDP back to the application.

It's not a protocol feature - more of an IDP feature - since it does this irrespective of the protocol.