PingFederate Server

Configuring standard IdP Discovery

SAML 2.0 identity provider (IdP) Discovery provides a cookie-based look-up mechanism to identify a user’s IdP dynamically during a service provider (SP)-initiated single sign-on (SSO) event when the IdP is not otherwise specified.

About this task

This mechanism can be helpful in cases where an SP might be a hub for several IdPs in an identity federation.

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.

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 can 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.

Steps

  1. Go to the Protocol Settings window.

  2. On the IdP Discovery tab, click Configure IdP Discovery.

  3. On the Domain Cookie Settings tab, choose the discovery role or roles of your PingFederate server.

  4. On the Common Domain Service tab, configure as follows.

    Field Description

    Base URL of the PingFederate Common Domain Service

    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 tab, 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 (.), as in the following 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 tab, review and modify settings as needed. Then click Save.

    Result:

    The administrative console brings you back to the IdP Discovery tab.

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

    When editing an existing configuration, you can 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:

    Choose from:

    • Make sure 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 on the Connection Options tab for the desired SP connection.