IdP discovery for a service provider application

One common architectural component that Service Provider (SP) websites need to implement is Identity Provider (IdP) Discovery, which is the capability to determine where authentication is to occur in cases where the SP website is a hub for several IdPs in an identity federation. In this scenario, a request comes to the SP website over the internet that is an anonymous transaction request, so the question to answer is how to determine where to route the request for authentication, or in terms of SSO which IdP to route the request for authentication. This is accomplished by an IdP Discovery architecture managed by the SP website.

Although the SAML Profile defines IDP Discovery, we do not see this capability used in practice very often since it requires a cookie to be written to the user’s browser prior to the request for the SP website. This is often not a practical solution for supporting a wide variety of architectures and users across the internet. Additionally, this doesn’t really fit well into newer federation protocols such as OAuth and OpenID Connect.

There are three common design patterns for IdP Discovery that we see in industry today, mainly,

• URL Proxy Discovery where the IdP is determined via domain information in the URL
• Home Realm Discovery where the IdP is determined via user information provided through a login username by looking at the domain of an email address
• Discovery Service where the IdP is determined via a browser-based interface that the user will select his or her preferred IdP

URL Proxy Discovery

We have found this design pattern to be the most useful solution for IdP Discovery. In this design pattern, a single-instance multi-tenant SP website would use the URL to determine the IdP (such as via a subdomain). For example, there are two main strategies, mainly https://domain1.spwebsite.com or https://www.spwebsite.com/domain1), where the “domain1” uniquely identifies the IdP server to use for identity federation. In terms of SAML integration, the URL would define the specific IdP server to federate along with a ACS URL back to the SP website that is configured uniquely for the IdP Server to maintain a high level of trust. Using the example URL https://domain1.spwebsite.com/resource, the backend server would process the “domain1” and redirect to the registered IdP server for “domain1” (e.g. https://sso.domain1.com/SSO) with the appropriate SAML AuthnRequest and associated ACS URL to receive the SAML Response.

Home Realm Discovery

Google and Microsoft Office365 provide examples that implement Home Realm Discovery, where the user is presented a login screen such that the username required is an email address. The backend server will determine that Federation SSO should be used based on the domain of the user’s email address. In the following example, the user has entered joe.bloggs@contoso.com as the email address. The backend server will detect the domain as contoso.com and determine if there is an associated IdP server registered with that domain. If there is a registered contoso.com domain, a redirect to the IdP Server will occur for the user to authenticate with that specific IdP. If there is not a registered contoso.com domain, then the website will authenticate the user and require a password.

Discovery Service

Generally speaking, a Discovery Service provides a browser-based interface where a user selects his or her preferred IdP for authentication. The SP website uses the selection to initiate the SSO transaction. One implementation used heavily in the educational industry is the InCommon “Where Are You From?” (WAYF), which is an implementation as much as it is an architecture. From the architecture point of view, the Discovery Service displays a web page to the user with all the valid IdP Servers to select. An example of the Discovery Service is located at https://cilogon.org/. Once the IdP is selected, the user will be routed to the IdP Server selected. In this case below, the user will then be routed to Google for authentication.

Designing and implementing a great experience for users on a SP website is essential, and for single-instance multi-tenant SP websites having an IdP Discovery capability is an absolute requirement. Contact us if you have questions on how to develop and implement IdP Discovery for your SP website.