PingFederate uses two connections to bridge an identity provider (IdP) to a service provider (SP). It fuses these two connections together by using an authentication policy contract, formerly known as a connection mapping contract, as the medium to carry user attributes from the IdP to the SP.
The two connections are:
- An IdP connection where end users authenticate and PingFederate, the federation hub, is the SP
- An SP connection to the target application where PingFederate, the federation hub, is the IdP
Each authentication policy contract comes with one default attribute, subject. You can extend the contract to include additional attributes as needed. In most federation hub use cases, you configure PingFederate to pull attribute values from inbound assertions into the authentication policy contract in an IdP connection and to push those values from the authentication policy contract into the outbound assertions through an SP connection. For advanced use cases, you can configure the IdP connections, SP connections, or both, to look up values from multiple data store instances.
When bridging one IdP to one SP, you must create one authentication policy contract and associate the contract with both the IdP connection and the SP connection.
When bridging one IdP to multiple SPs, you need to create an authentication policy contract per SP because each SP likely requires a different set of attributes. In addition, you need to map all the authentication policy contracts into the IdP connection and add the respective authentication policy contracts to each SP connection to the SP.
When bridging multiple IdPs to one SP, you likely need only one contract unless the SP requires a different set of attributes from each IdP. In addition, you need to add the authentication policy contract to the SP connection and the applicable IdP connections.
You can manage authentication policy contracts on the Policy Contracts window ( ).