Previous Topic: Enhanced Client or Proxy Profile Overview (SAML 2.0)Next Topic: SAML 2.0 HTTP-POST Binding Configuration

CA SiteMinder® Federation Standalone Guide › Single Sign-on Configuration › IDP Discovery Profile (SAML 2.0)

IDP Discovery Profile (SAML 2.0)

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.

IDP Discovery Configuration at the Identity Provider

You configure the IDP Discovery profile in the IDP Discovery section in the SSO and SLO dialog.

Note: Click Help for a description of fields, controls, and their respective requirements.

To enable the Identity Provider Discovery Profile

  1. Select the Enable IDP Discovery checkbox.
  2. Set the value for the Service URL field to the Identity Provider Discovery Profile servlet. For CA SiteMinder® Federation Standalone, this URL is:

    http://host:port/affwebservices/public/saml2ipd

    host

    Represents the common domain that you specify in the Common Domain field.

    port

    Specifies the Apache HTTP or HTTPS port you specified when installing CA SiteMinder® Federation Standalone.

    The URL can also begin with https.

  3. Specify the cookie domain in the Common Domain field.
  4. (Optional) Select the Enable Persistent Cookie check box to preserve the common cookie in the browser.

IdP Discovery is enabled at the IdP.

IDP Discovery Configuration at the Service Provider

For IDP Discovery profile, the Service Provider (SP) has to determine the Identity Provider (IdP) to which it sends authentication requests. The user that the SP wants to authenticate must have previously visited the Identity Provider and authenticated.

The SP has to redirect the user to its own IdP Discovery Service to retrieve the common domain cookie. The cookie contains the list of Identity Providers that the user has already visited. From this list, the cookie chooses the correct IdP and then sends an AuthnRequest to that IdP.

The IDP Discovery process is 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 IDP Discovery Service URL, indicating that it wants to get the Common Domain Cookie.
  3. The IDP Discovery Service gets the Common Domain Cookie, reads the cookie in its domain and redirects the user back to the site selection page. The discovery service provides Common Domain Cookie as a query parameter.
  4. The SP populates the site selection page with IdP URLs at which the user has previously authenticated.
  5. The user selects an IdP to perform the user authentication.

To configure IdP Discovery at the SP

  1. Create a site selection page that requests the Common Domain Cookie from the IdP Discovery Service at the SP.

    CA SiteMinder® Federation Standalone comes with a sample site selection page, named IdPDiscovery.jsp that the SP can use to implement IdP Discovery. You can find the page in the following directory:

    federation_install_dir/secure-proxy/Tomcat/
webapps/affwebservices/public

    The first link redirects the browser from one domain to the IdPDiscovery service in the common domain and retrieves the common domain cookie, named _saml_idp. When the IdP Discovery Service at the SP receives the request, it gets the common domain cookie and adds it as a query parameter. The IDP Discovery Service then redirects the user back to the IdPDiscovery.jsp site selection page in the regular domain. By default, the IdPDiscovery.jsp page displays only a list of IDs for the IdPs that it extracts from the common cookie. This list is static; there are no HTML links associated with the list that initiate communication with the associated IdP.

  2. Edit the following link on the sample page for your SP site. The first part of the link specifies the common domain where the saml2idp cookie resides. The second part of the link specifies the regular domain where the IdPDiscovery.jsp resides.

    For example:

    <a href="http://myspsystem.commondomain.com/affwebservices/public
/saml2ipd/?IPDTarget=/http://myspsystem.spdomain.com/affwebservices
/public/IdpDiscovery.jsp&SAMLRequest=getIPDCookie">
Retrieve idp discovery cookie from IPD Service</a>

    When the user is redirected back to the regular domain with the target site selection page, it now has the common cookie.

  3. (Optional) Edit the IdPDiscovery.jsp site selection page so it displays an HTML link for each IdP. Each link triggers an AuthNRequest to the IdP to initiate single sign-on. By default, the IdPDiscovery.jsp page only displays a list of IDs for the IdPs that it extracts from the common cookie.
  4. Use the edited site selection page to test IdP Discovery.

With IdP Discovery working, you can see the site selection page with a list of IdPs from which to select.

Securing the IdP Discovery Target Against Attacks

When the CA SiteMinder® Federation Standalone 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 and 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 used by the Web Agent, but this setting is defined specifically for federation.

When the IPD Service examines the IPDTarget query parameter, it obtains the domain of the URL specified by the query parameter. The IPD Service compares this domain to the list of domains specified for 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, no validation is done and the user is redirected to the target URL.