Remote users arriving at your site via an SSO request do so in order to use specific applications or gain access to protected resources. Based on the nature of the business relationship and the agreement with your partner, you may be expected to provide access to these applications. Therefore, integration between your federation SP server and local applications is important. PingFederate uses SP adapters to identify the user to your application based on attributes sent in an SSO token. A configured adapter is known as an adapter instance.
In a basic scenario, you map an SP adapter instance to an IdP connection on the Target Session Mapping screen and complete its mapping configuration through a series of sub tasks. When PingFederate receives an SSO token, the corresponding SP adapter is triggered to fulfill its adapter contract based on the connection settings (for the purpose of completing the "last-mile" integration with your application). As needed, you can map multiple SP adapter instances to an IdP connection, the same SP adapter instance to multiple IdP connections, or a combination of them.
Alternatively, if you use authentication policies to route users through a series of authentication sources and end each successful policy path with an authentication policy contract (APC), you can skip the mapping of an APC to an IdP connection and configure an APC-to-SP adapter instance mapping configuration.
To learn more about authentication policies, see Authentication policies.
Furthermore, you can map one or more APCs to an IdP connection to bridge an identity provider to one or more service providers. In this scenario, PingFederate is a federation hub for both sides. PingFederate uses APCs to associate this IdP connection with the applicable SP connections to the service providers; each APC has its own set of attributes which you map values from the SSO tokens.
To learn more about federation hub, see Federation hub use cases.
On the Target Session Mapping screen (if presented), you must associate at least one target session (an SP adapter instance or an authentication policy contract) with an IdP connection. If you have multiple integration requirements (for example, if you are using more than one IdM system or an application not covered by a centralized system), you should map multiple SP adapter instances. If you are bridging an identity provider to multiple service providers, you should map multiple authentication policy contracts.
Note that the Target Session Mapping configuration does not apply when the No Mapping option is chosen on the Identity Mapping screen.
- To map an SP adapter instance, click Map New Adapter Instance.
- To map an APC, click Map New Authentication Policy.
- To edit the mapping configuration of an SP adapter instance or APC, open it by clicking on its name, select the setting that you want to reconfigure, and complete the change.
- To remove an SP adapter or APC or cancel the removal request, click Delete (followed by Save) or Undelete.
- If you are creating a new connection and you are finished with mapping the required target sessions, click Done.
- If you are editing an existing configuration and want to keep your changes, click Save.
When target sessions are restricted to certain virtual server IDs, the allowed IDs are displayed under Virtual Server IDs.
If you configure multiple target sessions for a connection, PingFederate selects the applicable adapter instance or authentication policy contract at runtime based on the target resource information in the requests and your configuration (see Configuring target URL mapping).