Bridging multiple IdPs to multiple SPs - PingFederate - 10.3

PingFederate Server

bundle
pingfederate-103
ft:publication_title
PingFederate Server
Product_Version_ce
PingFederate 10.3
category
Product
pf-103
pingfederate
ContentType_ce

PingFederate can bridge single sign-on (SSO) and single log-out (SLO) transactions between multiple identity providers (IdPs) and service providers (SPs).

This PingFederate federation hub use case is a combination of Bridging an IdP to multiple SPs and Bridging multiple IdPs to an SP.

Diagram depicting the PingFederate Federation Hub and how it bridges multiples IdPs to multiple SPs.
  1. Create multiple contracts to bridge the attributes between the IdPs and the SPs. For more information, see Federation hub and authentication policy contracts.
  2. For each identity provider, create an IdP connection between the IdP and PingFederate, the federation hub as the SP.
  3. Add the applicable authentication policy contracts to the IdP connection in the Target Session Mapping window.
  4. In the Selectors window, configure an authentication selector to map each IdP to the corresponding IdP connection in an authentication policy. For example, see an instance of the Identifier First Adapter.
  5. For each service provider, create an SP connection between PingFederate, the federation hub as the IdP, and the SP.
  6. Add the corresponding authentication policy contract to the SP connection in the Authentication Source Mapping window.
    Important:

    PingFederate includes the Entity ID of the original IdP, Authenticating Authority, in SAML 2.0 assertions so that the SP can determine the original issuer of the assertions. This is especially important when bridging multiple IdPs to one SP—the SP should take the information about the original issuer into consideration before granting access to protected resources.

    In the Attribute Contract window, add an attribute for SAML 1.x assertions and WS-Federation security tokens. Then, in the Attribute Contract Fulfillment, map Context: Authenticating Authority as the attribute value.

    For information about Authenticating Authority, see section 2.7.2.2 Element <AuthnContext> in the SAML 2.0 specification.

    Note:

    If the SP does not take action based on Authenticating Authority, in the Issuance Criteria window, you can define validation rules to protect against user impersonation between IdPs.

  7. For each SP supporting the SAML IdP-initiated SSO profile, map the expected target resources to the corresponding SP connections in the Applications > Integration > Target URL Mapping window.
  8. Work with each IdP to connect to the federation hub as the SP.
  9. Work with each SP to connect to the federation hub as the IdP.