The /pf/adapter2adapter.ping endpoint initiates direct IdP-to-SP adapter mapping, mostly intended for the internal users to access resources without maintaining an SP and an 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 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 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.0, if you want to enforce multifactor 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, thus circumventing the SP authentication policy that is meant for them.
- An additional SP adapter instance, Sample Internal to integrate with the target application (step 1).
- An authentication policy contract, Internal authenticated, to carry attributes from internal users to the target applications.(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 (step 3).
- An authentication policy for the internal users (step 4).
- An adapter mapping to map from the authentication policy contracts Internal authenticated to the SP adapter instance Sample Internal (step 5)
- A new SSO URL for the internal users (step 6).
Follow these steps to fulfill the new requirements:
screen, create a new SP adapter instance:
Instance Name Instance ID Extended Contract Sample Internal sampleInternal subject and email
On to the Create New Contract to
create an authentication policy contract.
screen, click 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:
On the Create New Instance to
create an instance of the CIDR Authentication Selector with one or more network
ranges that correspond to your internal users.
screen, click 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. Another approach is to 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.
Go to the
screen to configure your policies as follows:
Internal authenticated.) to the new SP adapter instance (
sampleInternal). screen, create a mapping from the new authentication policy contract (On the Default Target URL screen, enter
Update the SSO URL for your internal users to: