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.

Screen capture of the 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/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.

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. 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.

  1. Go to Applications > Integration > SP Adapters.
  2. Click Create New Instance to create a new SP adapter instance.

    For each new instance, include the name, ID, and extended contract.

    Instance Name Instance ID Extended Contract
    Sample Internal sampleInternal subject and email
  3. Go to Authentication > Policies > Policy Contracts .
  4. Click Create New Contract to create an authentication policy contract.
    Note:

    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.
  5. Go to Authentication > Policies > Selectors.
  6. 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.
    Note:

    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. 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.

  7. Go to Authentication > Policies > Policies to configure your policies as follows.
    With PingID Adapter
    Screen capture of the SP authentication policy for internal users Screen capture of the SP authentication policies for Hotel users and internal users
    With CIDR Authentication Selector
    Screen capture of the SP authentication policy illustrating Internal users - (Selector) Screen capture of the SP authentication policy with completed Hotel users policy
  8. Go to Applications > Integration > Policy Contract Adapter Mappings.
  9. Click Create New Instance and create a mapping from the new authentication policy contract, Internal authenticated., to the new SP adapter instance, sampleInternal.
  10. On the Default Target URL window, enter https://sso.xray.local:9031/SpSample/MainPage/?app=Internal&t=i.
  11. Update the SSO URL for your internal users to https://sso.xray.local:9031/sp/startSSO.ping?SpSessionAuthnAdapterId=sampleInternal.