|
By Wajih Ahmed and Marina Sum, November 12, 2008; updated: December 8, 2008
|
|
|
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.
Contents
Prerequisites
It is assumed that you have established a premier account for Google Apps and downloaded the following software:
The example in this article uses GlassFish v2 Update Release 2 as the container.
Procedure
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:
- 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.
|
- 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.
Testing
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:
- 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.
- View the requests and responses in the debug log named
Federation. Here is an example.
Conclusion
Federating applications in OpenSSO is easy, quick, and intuitive—new wizards for common tasks eliminate guesswork and complexity.
References
|
 Wajih Ahmed, a senior systems engineer and technical specialist at Sun, is the Directory Services technology lead for the Americas and an identity specialist. Before joining Sun in 2001, he was a principal consultant in professional services at Netscape Communications.
|
 Marina Sum is a staff writer for Sun Developer Network. She has been writing for Sun since 1989, mostly in the technical arena. Marina blogs on Sun's products, technologies, events, publications, and unsung heroes.
|
|
Print-friendly Version
