In this use case, PingFederate is bridging SSO and SLO transactions between multiple identity providers and a service provider. For example, you are tasked to provide federated access to resources on Microsoft® SharePoint® for various business partners. With PingFederate, you can multiplex one SP connection (to SharePoint) to multiple IdP connections for all your business partners. The federation hub can also, as needed, translates SAML assertions from the business partners to WS-Federation security tokens and send them over to SharePoint.

  1. Enable both the IdP and the SP roles with the applicable protocols on the System > Protocol Settings > Roles & Protocols screen.
  2. Create a contract to bridge the attributes between the identity providers and the service provider (see Federation hub and authentication policy contracts). You likely need only one contract unless the service provider requires a different set of attributes from each identity provider.
  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. 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. Work with each identity provider to connect to PingFederate (the federation hub as the SP).
  7. Work with the service provider to connect to PingFederate (the federation hub as the IdP).