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

Tip:

In addition to supporting standard IdP Discovery, PingFederate provides a cross-protocol, proprietary mechanism that allows an SP server to write a persistent browser cookie. The cookie contains a reference to the previous IdP-authentication partner for SSO. For more information, see Configuring IdP discovery using a persistent cookie.

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 previously authenticated. Using this information, a PingFederate server can determine which IdP connection to use for sending an authentication request.

PingFederate can serve in up to three different IdP Discovery provider 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 past IdP authentications, 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.