The /pf/ 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/

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/

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:

SP authentication policy for Alpha users

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/

When you select the SP Authentication Policies check box without selecting the IdP Authentication Policies check box, the /pf/ 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.

To re-enable access to the application for the internal users, you need the following new components:
  • 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:

  1. On the Service Provider > Adapters screen, create a new SP adapter instance:
    Instance Name Instance ID Extended Contract
    Sample Internal sampleInternal subject and email
  2. On to the Service Provider > Policy Contracts screen, click Create New Contract to create an authentication policy contract.
    In this example, the name of the policy contract is Internal authenticated.

    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:

    • You map attributes to authentication policy contracts from authentication policies (step 4 in this example).
    • You map attributes from authentication policy contracts to target applications through adapter mappings (step 5 in this example).
  3. On the Service Provider > Selectors screen, click Create New Instance to create an instance of the CIDR Authentication Selector with one or more network ranges that correspond to your internal users.
    In this example, the name and ID are both Internal users.

    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.

  4. Go to the Service Provider > Policies screen to configure your policies as follows:
    With PingID Adapter
    SP authentication policy for internal users SP authentication policies for Hotel users and internal users
    With CIDR Authentication Selector
  5. On the Service Provider > Adapter Mappings screen, create a mapping from the new authentication policy contract (Internal authenticated.) to the new SP adapter instance (sampleInternal).
    On the Default Target URL screen, enter https://sso.xray.local:9031/SpSample/MainPage/?app=Internal&t=i.
  6. Update the SSO URL for your internal users to: