Single Sign-On for Java 3.3.2 - Administration Guide

Deployment options

To set up web applications for SSO using Single Sign-on for Java, you must set up your application server so that it can find Single Sign-on for Java's libraries (in the lib/ directory), and its required thirdparty libraries (in the thirdparty/lib directory).

There are several options to consider when deploying Single Sign-on for Java:

• Deploying in a web application
• Deploying on the CLASSPATH
• Deploying in application server specific path

The recommended approach for development and testing is to deploy Single Sign-on for Java into the web application itself.

Deploying in a web application

If you are deploying just a single web application it is possible to deploy all the necessary libraries in the WEB-INF/lib directory of the Web application.

This method has the benefit of being compact. All the necessary libraries are contained in the web applications distribution or war file and no special access to the Web Container and filesystem are necessary.

A drawback of this deployment method is that this makes the war file large and that other applications cannot share these libraries, so to deploy a second application, the libraries must be copied into the WEB-INF/lib of this application, too.

The libraries are loaded for each application which increases the memory footprint of the Web Container and using more resources such as file descriptors, etc.

Deploying on the CLASSPATH

Another deployment method is to set the required jars into the CLASSPATH variable before starting the Web Container. This allows the Web Container to take control of the specified jars without changing the JDK.

C:\> set CLASSPATH=file1.jar;file2.jar;...

C:\> startWebContainer.bat

This method is dependent on the Web Container that you are using and therefore may not be available.

A drawback of this method is that you must remember to set the variable before starting the Web Container. On the other hand, one benefit is the ability to switch between versions of libraries quickly by resetting the CLASSPATH variable and restarting the Web Container.

Some Web Containers also allow you set additional options for the JDK or JRE by including the JAVA_OPTIONS variable in the start command. The following example shows the Single Sign-on for Java Kerberos debugging being enabled under Windows.

C:\> set JAVA_OPTIONS=-Djcsi.kerberos.debug=true

C:\> startWebContainer.bat

Deploying in application server-specific path

Some Web Containers have their own deployment methods for common library jars. For example the Apache Tomcat servlet container allows additional libraries to be placed in the common/lib directory.

Refer to your Web Container documentation for more information on the installation and deployment of common libraries and the different variables that can be used to set options.