Federation Guides › Legacy Federation Guide › Configure CA SiteMinder® as a SAML 2.0 Service Provider › IDP Discovery Configuration at the Service Provider

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

Configure Identity Provider Discovery at the SP

Configuration of the Identity Provider Discovery profile at the Service Provider does not involve the Administrative UI. The profile is enabled in the Administrative UI at the Identity Provider.

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® 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:

   web_agent_home/affwebservices/public

   The first link on the site selection page redirects the browser from one domain to the IdP Discovery service in the common domain. The service gets the common domain cookie, named _saml_idp. When the IdP Discovery Service at the SP receives the request, it gets the common domain cookie. The service adds the common domain cookie as a query parameter to the link. The 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. The 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, the site selection page displays a list of IdPs from which to select.

Securing the IdP Discovery Target Against Attacks

When the CA 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.