Federation Security Services Guide › Federation Security Services Overview › Solutions for Federation Use Cases › Solution 10: Single Sign-on with No User ID at the IdP

Solution 10: Single Sign-on with No User ID at the IdP

Solution 10 shows how SiteMinder Federation Security Services can be deployed at smcompany.com and discounts.com to solve Use Case 10: SAML 2.0 Single Sign-on with No Name ID at the IdP.

SiteMinder is deployed at discounts.com and smwidgets.com by installing the Web Agent with the Web Agent Option pack on one machine, and the Policy Server with federation security services on another machine.

In the following illustration, smwidgets.com is acting as the Identity Provider and discounts.com is acting as the Service Provider.

Note: The SPS federation gateway can replace the Web Agent and Web Agent Option Pack to provide the SiteMinder Federation Web Services application functions. For information about installing and configuring the SPS federation gateway, see the CA SiteMinder Secure Proxy Server Administration Guide.

For single sign-on between the two sites, where there is no federated user identity at the Identity Provider, the sequence of events is as follows:

1. The user clicks on a link at discounts.com to take him to the target site. This link initiates a call to the local Policy Server to generate an authentication request. In this request, an optional attribute called AllowCreate has been included, based on the configuration of the SAML 2.0 authentication scheme at the Service Provider.
2. The Federation Web Services application at the local Web Agent redirects the request to the Single Sign-on service at the IdP, smwidgets.com.
3. The request is then forwarded to the IdP Policy Server, which generates an assertion. During assertion generation, the Policy Server searches for the attribute associated with the user requesting access. For example, the request may ask for the telephone number as the value of the Name ID.

   If the Policy Server cannot find a value for the telephone number attribute, it checks its configuration for the AllowCreate option. If this option is configured, the Policy Server searches the authentication request from the Service Provider to see if the AllowCreate option exists.

   If both sides have the Allow/Create feature enabled, the Policy Server generates a new identifier for the user attribute and places that identifier in its user store.

   Note: The identifier is the value of the user attribute.

4. The assertion is returned in a response message to the IdP Web Agent (FWS). The IdP returns a form to the browser containing the response, the Assertion Consumer URL, and the javascript to submit the form.
5. This form is posted to the Assertion Consumer Service at the Service Provider, which uses the response message to log in to the Policy Server using the response as credentials.
6. The Service Provider at smwidgets.com validates the credential by looking for the attribute in its user store, and assuming it finds the user, the user is logged in by the SAML authentication scheme.
7. The SP Web Agent creates an SMSESSION cookie for the smwidgets.com domain, places it in the user's browser, and redirects the user to the target destination.