SAML 2.0 IdP Discovery provides a cookie-based look-up mechanism used to identify a user's IdP dynamically during an SP-initiated SSO event, when the IdP is not otherwise specified. This mechanism can be helpful, in particular, in cases where an SP might be a hub for several IdPs in an identity federation.

Tip:

In addition to supporting SAML 2.0 IdP Discovery, PingFederate provides a cross-protocol, proprietary mechanism allowing a PingFederate SP server to write a persistent browser cookie. The cookie contains a reference to the IdP partner with whom the user previously authenticated for SSO. For more information, see Configuring IdP discovery using a persistent cookie.

Furthermore, an SP can also include the discovery mechanism within the application. For instance, an SP can provide vanity URLs to isolate one set of end users from the others based on the URL of the requested resources. Another possible solution is to provide a user interface for the end users to enter information about their identity providers. With this approach, the application can start an SP-initiated SSO request with information about the IdP.

In the standard scenario, when a user requests access to a protected resource on the SP, common-domain browser cookies are used to determine where a user has authenticated in the past. Using this information, a PingFederate server can determine which IdP connection to use for sending an authentication request.

As an IdP Discovery provider, PingFederate can serve in up to three different roles: common domain server, common domain cookie writer, and common domain cookie reader. Each of these roles is necessary to support IdP Discovery. The roles may be distributed across multiple servers at different sites.

Common domain server
In this role the PingFederate server hosts a domain that its federation partners share in common. The common domain server allows partners to manipulate browser cookies that exist within that common domain. PingFederate can serve in this role exclusively or as part of either an IdP or an SP federation role, or both.
Common domain cookie writer
When PingFederate is acting in an IdP role and authenticates a user, it can write an entry in the common domain cookie, including its federation entity ID. An SP can look up this information on the common domain (not the same location as the common domain server described above).
Common domain cookie reader
When PingFederate is acting as an SP and needs to determine the IdPs with whom the user has authenticated in the past, it reads the common domain cookie. Based on the information contained in the cookie, PingFederate can then initiate an SSO authentication request using the correct IdP connection.
  1. On the System > Protocol Settings > Roles & Protocols screen, select the IdP Discovery role.
  2. On the System > Protocol Settings > IdP Discovery screen, click Configure IdP Discovery.
  3. On the Domain Cookie Settings screen, choose the discovery role or roles of your PingFederate server.

    The choices that appear on this screen depend on whether PingFederate is acting as an SP, an IdP, both an SP and an IdP, or an IdP Discovery only server on the System > Protocol Settings > Roles & Protocols screen.

  4. On the Common Domain Service screen, configure as follows:
    Field Description
    Base URL Enter the base URL of the PingFederate common domain service.

    A common domain service is where PingFederate reads or writes authentication information contained in shared cookies, as determined by whether your site is an SP or IdP, respectively. (The service is shared if your PingFederate server is acting in both roles.) You must use HTTPS for the common domain.

    Pass Phrase and

    Confirm Pass

    Enter and confirm the pass phrase that web applications must use to access the domain.
  5. On the Local Common Domain Server screen, configure the required settings.

    A local common domain server is where PingFederate reads (as an SP) or writes (as an IdP) a common domain cookie (CDC) for IdP Discovery.

    Field Description
    Common Domain Enter the common domain.

    Your entry must include an initial period (.); for example:

    .example.com

    Cookie Lifetime (Days) Enter the lifetime of the CDC in days. The range is 1 to 1825 days. To indicate a non-persistent session cookie, enter -1.
    Pass Phrase and

    Confirm Pass

    Enter and confirm the pass phrase that web applications must use to access the domain.
  6. On the Summary screen, review and modify settings as needed. Then click Save.

    The administrative console brings you back to the System > Protocol Settings > IdP Discovery screen.

  7. Click Next and continue with the rest of the configuration.
    Tip:

    When editing an existing configuration, you may also click Save as soon as the administrative console offers the opportunity to do so.

  8. Perform one of the following actions to enable the setting of the common domain cookie at runtime:
    • Ensure that, prior to launching any SSO events, the web application that implements IdP Discovery sets the cookie using the /idp/writecdc.ping application endpoint intended for that purpose.
    • Enable setting the cookie at runtime during SSO events by selecting the IdP Discovery check box in the Connection Options screen for the desired SP connection.