The /pf/adapter2adapter.ping endpoint initiates direct IdP-to-SP adapter mapping, mostly intended for the internal users to access resources without maintaining a service provider (SP) and an identity provider (IdP) connection on the same server.
To prevent users from circumventing the SP authentication policies, this endpoint becomes inactive when SP authentication policies are enabled but IdP authentication policies are disabled. Administrators can configure SP authentication policies for the internal users to re-enable access to protected resources.
Suppose you have configured the following use cases in PingFederate 8.0.
For users from Hotel, an IdP:
- An SP adapter instance:
- Name: Sample Hotel
- ID: sampleHotel
- A SAML 2.0 IdP connection:
- Partner: Hotel
- Federation ID: sso.hotel.local
- SAML Profile: SP-initiated single sign-on (SSO) only
- Identity mapping method: Account mapping
- Default target URL: https://sso.xray.local:9031/SpSample/MainPage/?app=Hotel&t=h
- SSO URL: https://sso.xray.local:9031/sp/startSSO.ping?PartnerIdpId=sso.hotel.local
For internal users:
An IdP HTML Form Adapter instance, HTML Form, validating credentials through a Password Credential Validator (PCV) instance against your user directory
An adapter-to-adapter mapping:
- Source: HTML Form
- Target: Sample Hotel
- Default target URL: https://sso.xray.local:9031/SpSample/MainPage/?app=Internal&t=i
- SSO URL: https://sso.xray.local:9031/pf/adapter2adapter.ping?SpSessionAuthnAdapterId=sampleHotel
After upgrading to PingFederate 10.1, if you want to enforce multi-factor authentication for users from Hotel through Bravo, you can create an IdP connection to Bravo and the following authentication policy.
Because the authentication policy ends with a policy contract Hotel authenticated, you must create an adapter mapping, from the policy contract, to Sample Hotel, the SP adapter instance integrated with the target application. You also need to update the SSO URL for users from Hotel to https://sso.xray.local:9031/sp/startSSO.ping?SpSessionAuthnAdapterId=sampleHotel.
When you select the SP Authentication Policies check box without selecting the IdP Authentication Policies check box, the /pf/adapter2adapter.ping endpoint is disabled to prevent malicious Hotel's users, with specific knowledge of PingFederate endpoints, your PingFederate configuration, and functional credentials, from trying to access the target application through the SSO URL intended for your internal users. By doing so, you circumvent the SP authentication policy that is meant for them.
- An additional SP adapter instance, Sample Internal to integrate with the target application. See step 1.
- An authentication policy contract, Internal authenticated, to carry attributes from internal users to the target applications. See step 2.
- An instance of the CIDR Authentication Selector to be deployed in the authentication policy to reject users from external networks to access protected resources using your HTML Form Adapter. Alternatively, deploy an instance of the PingID Adapter in the authentication policy to enforce multifactor authentication for users who authenticated successfully using the HTML Form Adapter. See step 3.
- An authentication policy for the internal users. See step 4.
- An adapter mapping to map from the authentication policy contracts Internal authenticated to the SP adapter instance Sample Internal. See step 5.
- A new SSO URL for the internal users. See step 6.
Follow these steps to fulfill the new requirements.
- Go to .
Click Create New Instance to create a new SP adapter
For each new instance, include the name, ID, and extended contract.
Instance Name Instance ID Extended Contract Sample Internal sampleInternal subject and email
- Go to .
Click Create New Contract to create an authentication policy
In this example, the name of the policy contract is
The purpose of an authentication policy contract is to harness user attributes obtained through one or more authentication sources as the request flows through the applicable authentication policy. It is the medium between the authentication policies and the target applications. Generally speaking:
- Go to .
Click Create New Instance to create an instance of the CIDR
Authentication Selector with one or more network ranges that correspond to your
In this example, the name and ID are both
The purpose of the CIDR Authentication Selector is for the policy engine to reject users from external networks to access protected resources using your HTML Form Adapter. You can also deploy the PingID Adapter to enforce multifactor authentication for users authenticated through the HTML Form Adapter. If users fail to fulfill the PingID multifactor authentication requirement, the policy engine rejects their requests, thus providing another layer of protection against unauthorized access from malicious users.
to configure your policies as follows.
- Go to .
Click Create New Instance and create a mapping from the new
authentication policy contract,
Internal authenticated., to the new SP adapter instance,
On the Default Target URL window, enter
- Update the SSO URL for your internal users to https://sso.xray.local:9031/sp/startSSO.ping?SpSessionAuthnAdapterId=sampleInternal.