--- title: Configuring SP authentication policies for internal users description: 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. component: pingfederate version: 13.1 page_id: pingfederate:administrators_reference_guide:pf_config_sp_auth_policies_internal_users canonical_url: https://docs.pingidentity.com/pingfederate/13.1/administrators_reference_guide/pf_config_sp_auth_policies_internal_users.html llms_txt: https://docs.pingidentity.com/pingfederate/llms.txt docs_for_agents: https://developer.pingidentity.com/build-with-ai/docs-for-agents.md revdate: July 5, 2022 section_ids: about-this-task: About this task steps: Steps --- # Configuring SP authentication policies for internal users 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. ## About this task 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](_images/wws1564003330456.png) 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** checkbox without selecting the **IdP Authentication Policies** checkbox, 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](#pf_step_spAuthnPoliciesA2A_createSpAdapterInstance). * An authentication policy contract, **Internal authenticated**, to carry attributes from internal users to the target applications. See [step 2](#pf_step_spAuthnPoliciesA2A_createApc). * 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](#pf_step_spAuthnPoliciesA2A_createCideOrPingId). * An authentication policy for the internal users. See [step 4](#pf_step_spAuthnPoliciesA2A_createPolicyTwoChoices). * An adapter mapping to map from the authentication policy contracts **Internal authenticated** to the SP adapter instance **Sample Internal**. See [step 5](#pf_step_spAuthnPoliciesA2A_createAdapterMapping). * A new SSO URL for the internal users. See [step 6](#pf_step_spAuthnPoliciesA2A_newSsoUrl). Follow these steps to fulfill the new requirements. ## Steps 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. | | | | - | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | 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](#pf_step_spAuthnPoliciesA2A_createPolicyTwoChoices) in this example. - You map attributes from authentication policy contracts to target applications through adapter mappings, [step 5](#pf_step_spAuthnPoliciesA2A_createAdapterMapping) 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. | | | | - | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | 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. ![Screen capture of the SP authentication policy for internal users](_images/pur1564003331193.png)With PingID Adapter![Screen capture of the SP authentication policies for Hotel users and internal users](_images/ajp1564003331822.png)![Screen capture of the SP authentication policy illustrating Internal users - (Selector)](_images/lla1564003332566.png)With CIDR Authentication Selector![Screen capture of the SP authentication policy with completed Hotel users policy](_images/qdv1564003333194.png) 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.