Federation Security Services Guide › Federation Security Services Overview › Solutions for Federation Use Cases › Solution 12: SSO with Attributes from a Web Application

Solution 12: SSO with Attributes from a Web Application

Solution 12 shows how SiteMinder Federation Security Services can be deployed at IdPA.com and SPB.com to solve Use Case 12.

SiteMinder is deployed at both sites by installing the Web Agent with the Web Agent Option pack on one machine, and the Policy Server on another machine.

In the following illustration, IdPA.com is the Identity Provider and SPB.com is the Service Provider and single sign-on is initiated at the Identity 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 IdP-initiated single sign-on, the sequence of events is as follows

1. At the IdP, the user clicks on web page link and one of the following occurs:
   • The user is directed to IdPA.com's Single Sign-on (SSO) service. This service recognizes that the user does not have a session, so the user is redirected to the Authentication URL where he is prompted to log in. After successfully logging in, the user is redirected back to the SSO service. There is an application URL defined for the SSO service, which instructs the SSO service to redirect the user to a custom web application.

     Important! When the user goes to the SSO Service first, several query parameters (SPID, ProtocolBinding, RelayState) are included with the original SSO request. The SSO service groups this query data into one query parameter called SMPORTALSTATE, and then redirects the user (via a GET) to the web application.

   • The user logs in and is taken directly to the web application.

   Note: After the user is locally authenticated at the IdP, he is never redirected to the Authentication URL as long as he has a valid session.

2. Prompted by the web application, the user supplies the requested information. These attributes are POSTed to the SSO Service.

   Important! If the user starts at the SSO Service, and is redirected to the web application with the SMPORTALSTATE query parameter, the web application must POST the SMPORTALSTATE query parameter and the collected attributes back to the SSO Service.

3. The SSO service processes the SAML request. It unpacks the data from the SMPORTALSTATE parameter takes this data along with the attributes from the web application and passes all the POST data to the Assertion Generator.
4. The Assertion Generator creates the assertion.

   Important! The SSO Service makes all the attributes available to the Assertion Generator, but an Assertion Generator plug-in must be written and configured to add the attributes to the assertion.

5. After the assertion is generated, the user is redirected to the Assertion Consumer Service at the Service Provider, where the assertion is processed.
6. The user gains access to the requested resource at the Service Provider.

For SP-initiated single sign-on:

1. At the SP, the user clicks on a link and an AuthnRequest is sent to the Single Sign-on (SSO) service at the Identity Provider.

   Note: In the case of SP-initiated single sign-on, the request must arrive at the SSO service directly from the SP, as dictated by SAML specifications. The user cannot go directly to the web application.

2. At the IdP, the SSO service recognizes that the user does not have a session, so the user is redirected to the Authentication URL where he is prompted to log in. After successfully logging in, the user is redirected back to the SSO service. There is an application URL defined for the SSO service, which instructs the SSO service to redirect the user to a custom web application.

   Important! When the user is directed to the SSO Service, several query parameters (SPID, ProtocolBinding, RelayState) are included with the original SSO request. The SSO service groups this query data into one query parameter called SMPORTALSTATE, and then redirects the user (via a GET) to the web application.

3. Prompted by the web application, the user supplies the requested information. These attributes are POSTed to the SSO Service.

   Important! The web application must maintain and POST the SMPORTALSTATE query parameter and the collected attributes back to the SSO Service.

4. The SSO service processes the SAML request. It unpacks the data from the SMPORTALSTATE parameter takes this data along with the attributes from the web application and passes all the POST data to the Assertion Generator.
5. The assertion is generated with all the attributes and the user is redirected to the Assertion Consumer Service at the Service Provider, where the assertion is processed.

   Note: An Assertion Generator plug-in must be written and configured to add the attributes to the assertion.

6. The user gains access to the requested resource at the Service Provider.