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, translate SAML assertions from the business partners to WS-Federation security tokens and send them over to SharePoint.

Diagram depicting the PingFederate Federation Hub with multiple IdPs bridging to a single SP.
  1. Create a contract to bridge the attributes between the IdPs and the SP. For more information, see Federation hub and authentication policy contracts.
    You likely need only one contract unless the SP requires a different set of attributes from each IdP.
  2. For each IdP, create an IdP connection between the IdP and PingFederate, the federation hub as the SP.
  3. On the Target Session Mapping window, add the applicable authentication policy contracts to the IdP connection.
  4. On the Selectors window, configure an authentication selector. For example, see an instance of the Identifier First Adapter to map each IdP to the corresponding IdP connection in an authentication policy.
  5. 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 on 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.

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

    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, depending on the attributes from the IdPs, you can define validation rules on the Issuance Criteria window to protect against user impersonation between IdPs.

  7. Work with each IdP to connect to PingFederate, the federation hub as the SP.
  8. Work with the SP to connect to PingFederate, the federation hub as the IdP.