You can configure several service provider (SP) adapters to pass security tokens or other user credentials from the PingFederate SP server to the target resource via HTTP query parameters, cookies, or POST transmittal. In all cases, these transport methods carry the risk that a third party (with specific knowledge of the identity provider (IdP), the SP, or both, PingFederate endpoints, and PingFederate configuration) could obtain and use valid security tokens to gain improper access to the target resource.

This potential security threat involves using a well-formed SSO or SLO link to start an SSO or SLO request for a resource at the SP site. However, the target resource designated in the link intercepts the security token by a redirection to a malicious website. This same threat also applies to self-service user account management endpoints when such requests include the TargetResource parameter.

To prevent such an attack, PingFederate provides a means of validating SSO, SLO, and self-service user account management transactions to ensure that the designated target resource exists through a list of configurable URLs. At minimum, an expected resource requires a domain name (or an IP address) and the selection of one or more applicable request types.

Note:

The following default target URLs are always allowed, and you don't need to enter them into the list manually:

PingFederate can also validate the error resource parameter. For more information about the InErrorResource parameter, see IdP endpoints, SP endpoints and System-services endpoints.

Important:

PingFederate enables both target resource validation and error resource validation by default in new installations.

For backward compatibility, PingFederate upgrade tools do not enable these options if they aren't selected in the previous PingFederate installation. Although optional, we strongly recommend enabling validation for both target and error resources and entering all expected resources (including the HTTPS option) to prevent unauthorized access.

  1. Go to Security > System Integration > Redirect Validation.
  2. Configure target resource validation options.
    Option Description
    SSO When selected, PingFederate validates the requested target resource for IdP connections, adapter-to-adapter mappings, and SAML 2.0 IdP Discovery against a list of configurable resources.

    This check box is selected by default in new installations.

    Clear the check box to disable the feature.

    SLO and Other When selected, PingFederate validates the requested target resource for SLO and self-service user account management requests against a list of configurable resources.

    This check box is selected by default in new installations.

    Clear the check box to disable the feature.

  3. Configure error resource validation.
    Note:

    Select the Enable InErrorResource Validation check box to validate the requested InErrorResource parameter value against a list of configurable resources.

    This check box is selected by default in new installations.

    Clear the check box to disable the feature.

  4. Define a list of expected resources.
    1. Indicate whether to mandate secure connections when this resource is requested under Require HTTPS.
      Important:

      This selection is recommended to ensure that the validation will always prevent message interception for this type of potential attack, under all conceivable permutations.

      This check box is selected by default.

    2. Enter the expected domain name or IP address of this resource under Valid Domain Name.

      Enter a value without the protocol, such as example.com or 10.10.10.10.

      Prefix a domain name with a wildcard followed by a period to include subdomains using one entry. For instance, *.example.com covers hr.example.com or email.example.com but not example.com, the parent domain.

      Important:

      While using an initial wildcard provides the convenience of allowing multiple subdomains using one entry, consider adding individual subdomains to limit the redirection to a list of known hosts.

    3. Optional: Enter the exact path of this resource under Valid Path.

      Start with a forward slash, without any wildcard characters in the path. If left blank, any path under the specified domain or IP address is allowed. This value is case-sensitive. For instance, /inbound/Consumer.jsp allows /inbound/Consumer.jsp but rejects /inbound/consumer.jsp.

      You can allow specific query parameters with or without a fragment by appending them to the path. For instance, /inbound/Consumer.jsp?area=West&team=IT#ref1001 matches /inbound/Consumer.jsp?area=West&team=IT#ref1001 but not /inbound/Consumer.jsp?area=East&team=IT#ref1001.

    4. Optional: Select the check box under Allow Any Query/Fragment to allow any query parameters or fragment for this resource.

      Selecting this check box also means that no query parameter and fragment are allowed in the path defined under Valid Path.

      This check box is not selected by default.

    5. Select one or more request types for this resource.
      • Select the check box under TargetResource for SSO if this is an expected SSO target resource for one or more IdP connections, adapter-to-adapter mappings, or SAML 2.0 IdP Discovery.
      • Select the check box under TargetResource for SLO and Other if this is an expected target resource for SLO and self-service user account management requests.
      • Select the check box under InErrorResource if this is an expected InErrorResource parameter value.

      These check boxes are not selected by default.

    6. Click Add.

      Use the Edit, Update, and Cancel workflow to make or undo a change to an existing entry. Use the Delete and Undelete workflow to remove an existing entry or cancel the removal request.

    7. Repeat these steps to define multiple expected resources.
      Note: The display order does not matter. A more specific match is considered a better match and an exact match is considered the best match.
  5. Click Save.