Previous Topic: Create a Policy to Implement Attributes as HTTP HeadersNext Topic: Customize Assertion Processing with the Message Consumer Plug-in


IDP Discovery Configuration at the Service Provider

The Identity Provider Discovery (IPD) profile provides a common discovery service that enables a Service Provider to select a unique IdP for authentication. A prior business agreement between partners is established so that all sites in the network interact with the Identity Provider Discovery service.

This profile is useful in federated networks that have more than one partner providing assertions. A Service Provider can determine which Identity Provider it sends authentication requests for a particular user.

The IdP Discovery profile is implemented using a cookie domain that is common to the two federated partners. A cookie in the agreed upon domain contains the list of IdPs that the user has visited.The SP has to redirect the user to the IdP Discovery Service to retrieve the common domain cookie. The cookie contains the list of IdPs that the user has already visited. From this list, the SP chooses the correct Identity Provider and then sends an AuthnRequest.

Note: The user requiring authentication must have previously visited the Identity Provider and authenticated.

IDP Discovery occurs as follows:

  1. The browser requests the site selection page at the SP.

    This site selection page is aware of the IDP Discovery Service URL.

  2. The site selection page redirects the user to the IDP Discovery Service URL in the common domain. The redirect URL contains a query parameter indicating that it wants the Common Domain Cookie.
  3. The IDP Discovery Service retrieves the value of the Common Domain Cookie and sets it as a query parameter. The service then redirects the user back to the site selection page at the SP.
  4. The SP populates the site selection page with IdP IDs, which are URIs at which the user has previously authenticated.
  5. The user selects an IdP to perform the user authentication.

More information:

Configure Identity Provider Discovery at the IdP

Securing the IdP Discovery Target Against Attacks

When the SiteMinder Identity Provider Discovery Service receives a request for the common domain cookie, the request includes a query parameter named IPDTarget. This query parameter lists a URL where the Discovery Service must redirect to after it processes the request.

For an IdP, the IPDTarget is the SAML 2.0 Single Sign-on service. For an SP, the target is the requesting application that wants to use the common domain cookie.

We recommend protecting the IPDTarget query parameter against security attacks. An unauthorized user can place any URL in this query parameter. The URL can cause a redirection to a malicious site.

To protect the query parameter against an attack, configure the Agent Configuration Object setting ValidFedTargetDomain. The ValidFedTargetDomain parameter lists all valid domains for your federated environment.

Note: The ValidFedTargetDomain setting is similar to the ValidTargetDomain setting that the Web Agent uses, but this setting is defined specifically for federation.

The IPD Service examines the IPDTarget query parameter. The service obtains the domain of the URL that the query parameter specifies. The IPD Service compares this domain to the list of domains specified in the ValidFedTargetDomain parameter. If the URL domain matches one of the configured domains in the ValidFedTargetDomain, the IPD Service redirects the user to the designated URL.

If there is no domain match, the IPD Service denies the user request and they receive a 403 Forbidden in the browser. Additionally, errors are reported in the FWS trace log and the affwebservices log. These messages indicate that the domain of the IPDTarget is not defined as a valid federation target domain.

If you do not configure the ValidFedTargetDomain setting, the service redirects the user to the target URL without performing any validation.

More information:

Solution 7: Identity Provider Discovery Profile (SAML 2.0)