Federated Single Sign-On for Google Apps in OpenSSO

With OpenSSO, Sun's open-source Web access management project, you can implement federation for applications, such as Google Apps, for single sign-on (SSO) in just a few steps. Google Apps are widely adopted by enterprises for email, calendar, and collaboration through Google Docs, Google Video, and so forth.

This article steps you through the federation process, whereby OpenSSO acts as the identity provider (IdP) and Google Apps as the service provider (SP). Security Assertion Markup Language (SAML) version 2 serves as the SSO protocol for creating a Circle of Trust on the IdP.

Note: Four of the five steps that follow are demonstrated in videos. To play them on your browser, you must have the Apple QuickTime plug-in installed.

It is assumed that you have established a premier account for Google Apps and downloaded the following software:

• Sun OpenSSO Enterprise 8.0 (henceforth, OpenSSO Enterprise), the latest commercial release of OpenSSO; or the latest Sun OpenSSO Express stable build (build 6 or later)
  
  
• An OpenSSO-supported Web container (see "Supported Web Containers" on page 11 of the Sun OpenSSO Enterprise 8.0 Release Notes for the choices)

The example in this article uses GlassFish v2 Update Release 2 as the container.

Important: Before implementing for production, be sure to enable Secure Sockets Layer (SSL) on all your Web server instances.

First, perform the predeployment tasks for your container, as described in the OpenSSO Enterprise Release Notes. Afterwards, do the following:

Step 1: Deploy the OpenSSO WAR File
Once you've downloaded OpenSSO Enterprise in the form of a ZIP file, unzip the file, go to the deployable-war directory, and deploy the opensso.war file on your container. For GlassFish, do the following:

1. Become root and type:
   
   

   # ./asadmin deploy --user admin --passwordfile /var/tmp/asadmin_passwd --port 4848 --enabled=true --contextroot /opensso /var/tmp/opensso/deployable-war/opensso.war

    
   GlassFish confirms the deployment:
   
   

   Command deploy executed successfully.

    
   
2. Stop and restart GlassFish. Here are the commands and example output:
   
   

   # ./asadmin stop-domain Domain idp stopped. # ./asadmin start-domain Starting Domain idp, please wait.Log redirected to /var/opt/glassfish/domains/idp/logs/ server.log. Redirecting output to /var/opt/glassfish/domains/idp/logs/server.log Domain domain1 is ready to receive client requests. Additional services are being started in background. Domain [idp] is running [Sun Java System Application Server 9.1_02 (build b04-fcs)] with its configuration and logs at: [/var/opt/glassfish/domains]. Admin Console is available at [http://localhost:4848]. Use the same port [4848] for "asadmin" commands. User web applications are available at these URLs: [http://localhost:8080 https://localhost:8181 ]. Following web-contexts are available: [/web1 /__wstx-services /opensso ]. Standard JMX Clients (like JConsole) can connect to JMXServiceURL: [service:jmx:rmi:///jndi/rmi://utopia:8686/jmxrmi] for domain management purposes. Domain listens on at least following ports for connections: [8080 8181 4848 3700 3820 3920 8686 ]. Domain does not support application server clusters and other standalone instances.

    
   Alternatively, you can perform the preceding steps in the GlassFish Administration Console.

Note: If you use a container other than GlassFish, you might have to update the container's server.policy file. Again, refer to the OpenSSO Enterprise Release Notes.

Step 2: Configure OpenSSO
Next, run the OpenSSO configuration wizard on your browser by accessing the container and the OpenSSO context. The URL for our example is http://idp.unopass.net/opensso.

See this video for the configuration steps.

Step 3: Configure the IdP on OpenSSO
The OpenSSO workflow wizard in the Administration Console guides you through the process of creating a hosted or remote IdP and SP. Hence, you need not create a metadata file and import it manually.

Follow the steps in this video.

Step 4: Configure the SP on Google Apps
Now configure the SP, as demonstrated in this video.

Step 5: Map the Name Identifier
Google Apps requires a return of the user ID in the SAML response. Even though it does not perform this task by default, OpenSSO offers a simple way of mapping the ID ( NameID) to any attribute in the user profile in the LDAP directory.

Follow the steps in this video.

Note: Be sure to first create a user account if it does not already exist in OpenSSO.

Finally, test the federation by going to http://mail.google.com/a/ domain_name. If SSO works, you will be redirected to the OpenSSO login screen instead of the traditional Google login screen. Simply sign in with the appropriate user ID and password.

Behind the scenes are many exchanges of SAML v2-based Simple Object Access Protocol (SOAP) messages. To take a look, do the following:

1. In the OpenSSO Administration Console, choose Configuration > Sites > http:// domain_name: portnumber and then change the debug level to message.
   
   This change is dynamic; you need not restart the container for the change to take effect.
   
   
2. View the requests and responses in the debug log named Federation. Here is an example.

Federating applications in OpenSSO is easy, quick, and intuitive—new wizards for common tasks eliminate guesswork and complexity.

• OpenSSO
  • Main page
  • Resource Center
  • Support: Sun OpenSSO Express
  
  
• GlassFish Application Server
  
  
• Sun developer services
  • Support
  • Training and certification