Defining a service URL (WS-Federation) - PingFederate - 10.3

PingFederate Server

bundle
pingfederate-103
ft:publication_title
PingFederate Server
Product_Version_ce
PingFederate 10.3
category
Product
pf-103
pingfederate
ContentType_ce

On the Service URL tab, you can enter the WS-Federation protocol endpoint of your service provider (SP) partner where PingFederate will send single sign-on (SSO) tokens and single logout (SLO) cleanup messages.

For prerequisites and initial steps for configuring Browser SSO protocols, see Configuring protocol settings.

The SSO tokens are transmitted within a Request for Security Token Response (RSTR) message in response to a request for authentication from the SP. SLO cleanup messages are sent to your partner when PingFederate, as the identity provider (IdP), receives a user's SLO request. These cleanup messages indicate that the user's local session has been terminated.

To protect against session token hijacking, you can specify additional allowed domains and paths on this window. If the option to validate wreply for SLO is enabled, these additional domains and paths will also be taken into consideration as well. For more information, see Managing partner redirect validation.

Some federation use cases might require additional customizations in the RSTR message sent from the PingFederate IdP server to the SP. You can use OGNL expressions to fulfill these use cases.

  1. On the Service URL tab, enter the WS-Federation protocol endpoint at the SP site in the Endpoint URL field.

    You can enter a relative path (begin with a forward slash) if you have provided a base URL on the General Info tab. For more information, see Identifying the SP.

  2. Optional: Specify additional allowed domains and paths.
    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. 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.

    6. 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.
  3. Optional: Customize messages using OGNL expressions.

    Expressions are not enabled by default. For more information about enabling and editing OGNL expressions, see Attribute mapping expressions.

    1. Click Show Advanced Customizations.
    2. Select a message type from the list.
    3. Enter an OGNL expression to fulfill your use case.
      Note:

      For more information about Message Type, available variables, and sample OGNL expressions, see Customizing assertions and authentication requests.

    4. Click Add.
    5. Optional: Repeat to add another message customization.
  4. Click Next to save your changes.

If you are editing an existing connection, you can reconfigure any items, which might require additional configuration changes in subsequent tasks.