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

Federation hub diagram
  1. Enable both the IdP and the SP roles with the applicable protocols on the System > Protocol Settings > Roles & Protocols screen.
  2. Create multiple contracts to bridge the attributes between the identity providers and the service providers (see Federation hub and authentication policy contracts).
  3. For each identity provider, create an IdP connection between the identity provider and PingFederate (the federation hub as the SP) and add to the IdP connection the applicable authentication policy contract(s) on the Target Session Mapping screen.
  4. On the Selectors screen, configure an authentication selector (for example, an instance of the Identifier First Adapter) to map each identity provider to the corresponding IdP connection in an authentication policy.
  5. For each service provider, create an SP connection between PingFederate (the federation hub as the IdP) and the service provider and add to the SP connection the corresponding authentication policy contract on the Authentication Source Mapping screen.
    Important:

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

    For SAML 1.x assertions and WS-Federation security tokens, you can add an attribute on the Attribute Contract screen and then map Context: Authenticating Authority as the attribute value on the Attribute Contract Fulfillment screen.

    For information about Authenticating Authority, see section 2.7.2.2 Element <AuthnContext> in the SAML 2.0 specification (https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf)

    Note:

    If the service provider does not take action based on Authenticating Authority, depending on the attributes from the identity providers, you may define validation rules on the Issuance Criteria screen to protect against user impersonation between IdPs.

  6. For each service provider supporting the SAML IdP-initiated SSO profile, map the expected target resources to the corresponding SP connections on the Service Provider > Target URL Mapping screen.
  7. Work with each identity provider to connect to the federation hub (as the SP).
  8. Work with each service provider to connect to the federation hub (as the IdP).