Single Sign On (SSO) for Tomcat

Are customer of mine asked advice to enable single-sign-on in his J2EE application. Currently they have multiple applications running in their own tomcat server. As usual there is no one size fits all.

Solution 0: Do It Yourself

Security is dangers and only done right by good people . Just kidding....
You SHOULD NOT DO THIS ;-) You will not keep up with new authentication schemes, bugs ...

Solution 1: Non-Clustered SSO:
Deploy all applications within the same Tomcat/ Virtual host

Tomcat 4.x:
Tomcat 5.x

(cfr. http://wiki.jboss.org/wiki/SingleSignOn)

Pro: You can use the Tomcat internal mechanism that allows SSO for all applications within it's container

Cons: This might not work if these applications share different domains (http://www.one.com, http://www.two.com)

Solution 2: Clustered SSO:

This would allow you to do clustering over different domains or different Tomcats. But it seems that Tomcat itself did not implement it, but Jboss extended it .

<Valve className="org.jboss.web.tomcat.tc5.sso.ClusteredSingleSignOn"<br />              treeCacheName="jboss.cache:service=TomcatClusteringCache" debug="0 >

Related you might want to have a look at session replication, or how to direct the traffic to the correct server:

Tomcat 6: http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html
Tomcat 5: http://www.onjava.com/pub/a/onjava/2004/12/15/replication2.html
http://helpme.morphexchange.com/tomcat6/help/items/chapter_20_clustering
http://tomcat.apache.org/connectors-doc/ -> mod_jk -> Sticky Ness ( session replication)
http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/catalina/ha/authenticator/ClusterSingleSignOn.html

It seems work is still going on: "org.apache.catalina.ha.authenticator.ClusterSingleSignOn"
http://books.google.be/books?id=vJttHyVF0SUC&pg=PA310&lpg=PA310&dq=org.apache.catalina.ha.authenticator.ClusterSingleSignOn&source=web&ots=i_4zsZqRh2&sig=1MaqgULENG-DjCHwSkgdNgcjWuU&hl=nl&sa=X&oi=book_result&resnum=3&ct=result#PPA310,M1
google of summer code (2006): http://fabien.carrion.free.fr/TomcatCluster.html

Pro: Add additional redundancy
Cons: complex not really supported in Tomcat itself,not well documented, Clustering is not easy for tomcats in different locations/ISP's.

Solution 3: Tomcat behind a webproxy
In this case a web proxy f.i. apache) will handle the authentication and passes remote_user environment variable to the servlet so that it can check the username once authenticated.

Pro: Removes the need for clustering of doing your own authentication
Cons: users are managed elsewhere, a new critical component (if proxy is down, no site is available), routing traffic over the internet is not adviced: A proxy will be at one location and needs to fetch data from another application

Solution 4: Tomcat with agents of a dedicated SSO solution
Every large vendor has started to create it's own SSO solution. In essence it often consists of a dedicated application for authentication which has multiple plugins for authentication schemas and allows you to create sessions and has a slick UI for managing rules and users.

Pro: if you are familiar with filters and deploying war files most things should come out of the box.
Cons: vendor lock in; well not really but you are installing agents and become dependent on the API provide. So choose wise.

http://www.simongbrown.com/blog/2004/11/04/1099588633312.html
Josso: http://www.josso.org/confluence/display/JOSSO1/JOSSO+-+Java+Open+Single+Sign-On+Project+Home
Open SSO: http://blogs.sun.com/superpat/entry/opensso_on_tomcat_in_ubuntu
Novel, JBoss, Oracle, Atlassia, ...