Single Sign On (JBoss-3.2.3)
The tomcat4.1.x/5.0.x single sign-on behavior has been updated to allow for propagation of the web app security context to the ejb container and other secured resources.
Configuration: In the jbossweb-tomcat41.sar/META-INF/jboss-service.xml file,
inside the element of any virtual hosts for which you want
single sign-on support, add an element:
< Valve className="org.jboss.web.tomcat.tc4.authenticator.SingleSignOn" debug="0"/ >
For Tomcat 5.x: jbossweb-tomcat50.sar/server.xml
<!-- Uncomment to enable single sign-on across web apps deployed to this host. <Valve className="org.apache.catalina.authenticator.SingleSignOn" debug="0"></Valve> -->
The "debug" attribute specifies the detail level of debugging messages created by this component.
By default, this is set to zero (0), which means no debug output. A value of two (2) produces
a large amount of output, similar to DEBUG or TRACE level logging with Log4j.
Please note the Tomcat SingleSignOn valve stores SSO keys in a map maintained in the
local JVM; it is not shared across a cluster. This release does not deal with that limitation;
it allows SSO between multiple webapps deployed on one server, but it isn't cluster-aware.
Notes on mixing different authentication schemes in webapps under the same virtual host:
There are some differences between the way this valve works and the way the standard Tomcat valve
works in a situation where different webapps under the same virtual host use different authentication
schemes. This is because JBoss requires that each request from the user be reauthenticated; therefore
when each request comes in, the SingleSignOn valve needs to have available in its cache sufficient
security information to reauthenticate the user.
If when accessing a virtual host the user first visits a webapp that uses FORM or BASIC authentication, and then they visit another webapp that requires DIGEST, the cached username/password from the FORM/BASIC authentication will not be sufficient information to do a digest authentication, so the user will be prompted for a digest login. Once a digest login succeeds, the browser automatically sends authentication information with each request, so thereafter the user can switch between DIGEST and FORM/BASIC webapps without issue
Custom Principals and Classloader-issues
If you use custom principal implementations in your login modules in isolated EAR-files, you need to make sure that their classloaders will use exactly the same library.
You can guarantee this by putting the principal object (and other associated objects) into server/default/lib directory and removing them from your WAR/EAR files.
You can track this by looking into the isolated loader-repositories in the JMX-console and make sure the libraries used are located in server/default/lib.
Clustered Single Sign On (JBoss-3.2.4 and JBoss-3.2.5)
As of the JBoss-3.2.4 release, there is support for single sign-on of web applications across a cluster, using JBossCache for SSO credential caching and replication.
Configuration: In the jbossweb-tomcat50.sar/server.xml file,
inside the element of any virtual hosts for which you want single sign-on support,
add an element:
<Valve className="org.jboss.web.tomcat.tc5.sso.ClusteredSingleSignOn" treeCacheName="jboss.cache:service=TomcatClusteringCache" debug="0"></Valve>
If using the Clustered Single Sign On valve, be sure the standard single sign on valve described above is commented out.
The Clustered Single Sign On valve depends on the existence of a JBossCache MBean, which must be separately configured. An example service.xml file for such an MBean is attached to this page; to deploy the JBossCache MBean, just copy the attached file to the server/all/deploy directory. Note that the value of the treeCacheName attribute of Clustered Single Sign On valve element in server.xml must match the JMX object name of the JBossCache MBean.
Clustered Single Sign On (JBoss-3.2.6 and JBoss-4.0)
Beginning with the JBoss-3.2.6 release, the Clustered Single Sign On valve by default shares a JBossCache MBean with the clustered Http Session replication service. This means users do not themselves need to deploy the attached tc5-cluster-service.xml file; it is already deployed as part of the standard JBoss "all" configuration.
To use the clustered single sign on valve, edit the jbossweb-tomcat50.sar/server.xml file and inside the element of any virtual hosts for which you want single sign-on support, add an element:
<Valve className="org.jboss.web.tomcat.tc5.sso.ClusteredSingleSignOn" debug="0"></Valve>
Setting the treeCacheName attribute is no longer necessary, as the valve defaults to using the JBossCache MBean deployed via the tc5-cluster-service.xml file found in the server/all/deploy directory. If you wish to use a different JBossCache MBean, the configuration method used in JBoss-3.2.4 is still available; just deploy a service.xml file for your JBossCache and set the clustered single sign on valve's treeCacheName attribute to point to it.
Logging Changes (JBoss 4.0.2 and up)
Beginning with JBoss 4.0.2, the debug attribute discussed above was disabled in the standalone Tomcat SingleSignOn valve and in the Clustered Single Sign On valve. The valve's logging is now controlled via the log4.xml file in the JBoss conf folder. Unfortunately, the log category that controls the valve is a little obscure -- the valve shares a logger with the Tomcat container that contains it. Use the following to get DEBUG level logging:
<category name="org.apache.catalina.core.ContainerBase"> <priority value="DEBUG"></priority> </category>
This will log somewhat more than just the SSO valve's output, but not excessively so.