The Identity Provider Discovery Problem

From Project Concordia

Jump to: navigation, search

At DIDW (see the DIDW Workshop 2007 Notes), we began discussing the conundrum of identity provider discovery and agreed to do the following:

  • Do a survey of how it's done and how painful the current methods are
  • Collect usability data
  • Do education and share knowledge about the issue (everyone hates each individual way, but add it all up and you still have to pick a way!)

This page serves as our repository of educational material on IdP discovery. The "champions" of this effort, as discussed in October, are Scott Cantor, Eve Maler, Jeff Hodges, and George Fletcher.

Problem Statement

In brief: When the source of a user's identity and authentication information (identity provider or IdP) is different from where the information is consumed (the service provider or SP, also known as the relying party or RP), certain scenarios require the RP to initiate contact with the IdP in order to accomplish single sign-on or other similar federated identity activities. This requires that the RP know how to locate the IdP.

In more detail: SSO is commonly deployed in one of two major styles. An IdP that serves users as a one-stop portal to RP websites (typically a known set of partners) is the simpler style, and because the IdP initiates contact with each RP (called IdP-initiated SSO), it has no discovery problem. A more complex style is SP-initiated SSO, in which users can approach (or bookmark) the website belonging to an RP directly; it is only when a user asks for protected resources at this site that the site must then begin a conversation with the user's IdP. But which IdP, where on the network? That is indeed the problem.

Solution Categories

As first discussed in October (see the notes from Concordia telecon 9 Oct 2007), following is intended to be a comprehensive list of the options we can think of for IdP discovery, with the typical logical components (IdP, RP, user, user agent) in the picture:

  1. The user tells the RP
    1. By choosing from GUI selections (e.g., InCommon Federation-style drop-down list)
    2. By directly typing in a location (e.g., OpenID-style)
  2. The RP is pre-configured to know the IdP
  3. The RP communicates with a separate service (the Where Are You From? or WAYF approach) that asks the user
  4. The client device tells the RP
    1. By means of a cookie (e.g., SAML IdP Discovery common domain cookie method)
    2. By being pre-configured to know the IdP's location (e.g., a special browser plug-in or a SAML Enhanced Client or Proxy)
    3. By mediating a query/response conversation at a low protocol level (e.g., doing SPNEGO underneath HTTP) [@@I don't know if this is the right way to categorize this input from Scott; please feel free to correct/move it. -Eve]
  5. The client device is synonymous with the IdP (e.g., self-asserted cards or self-hosted IdPs)
  6. The client device serves as a proxy for the IdP, removing the need for direct RP communication with the IdP (e.g., managed cards)

Analysis of IdP Discovery Solutions

Following are observations on the consequences of choosing each of the solutions and sub-solutions listed above.

Obviously option one is simpler for the IT infrastructure, but it makes like hard for the user. Many users may not even know where they are from in an identity context. In my mind this is the worst case fall back, and if it is exercised, at least the system should make some effort to use terminology of relevence to the end user, and perhaps order the choices in order of probability that they are correct.

TBS

Retrieved from "http://projectconcordia.org/index.php/The_Identity_Provider_Discovery_Problem"