SIDEBAR

Tivoli Access Manager
The production security configuration followed the recommendations for Tivoli implementations published by IBM. The setup consisted of two WebSEAL servers, two Web/application servers, one policy server, and a master/replica LDAP configuration. The application servers hosted all of the applications with WebSEAL tying to each application through an IP/Port specific junction (a "junction" is a resource mapping and defines the true location of a URI). This necessitates multiple network cards in the WebSEAL machines in order to support multiple host addresses that are on the standard Web port.

Each production WebSEAL instance had numerous junctions configured to the multiple applications. The configuration was also set up for failover by ensuring that the server UUID configured in the junctions matched on each machine; therefore cookies for session fail-over could be picked up by either WebSEAL instance.

Choosing to install the Authorization Server on each application server created policy server redundancy. The authorization servers act as a replica of Policy server information. As a default, when the authorization server is installed, the application server does not hit the policy server directly in most cases because it obtains authorization information directly from the authorization server. The only time the policy server is reached is for any account updates. All these settings can be found in a configuration file (webseald.conf). Choosing to follow the authorization server route ensures application availability in case the policy server is down - it's a more economical method for fail-over than a master/replica policy server configuration.

Sidebar 2

Configuring Ant for Deployments Between Different Application Servers
We used Ant (Ant 1.6+) to manage configuration, builds, and deployments from local development environments to the integration server, from there to the staging server, and finally to production. The ant scripts needed to handle two main server differences:

1. The WEB-INF/lib directory had to be populated with any JARs not provided by the application server. Specifically, our Tomcat environment required the optional JDBC 2.0 Package while WebSphere already came with the necessary classes installed.
2. The security-* elements of the Web deployment descriptor (web.xml) needed to include security-role definitions for deployments to Tomcat. In WebSphere, the security roles were defined at the enterprise application level (application.xml). The solution was to treat any environment dependencies through parameters and to create configuration files that contained all settings for a server type. We laid the groundwork by explicitly providing a value for the server.type Ant property:

   <!-- Server Type property-override customizations (if any) -->
   <property name="server.type.config.file"
   location="${build.modules.home}/deployment/servertypes/${server.type}.properties"/>
   <echo message="server.type.config.file=${server.type.config.file}"/>
   <property file="${server.type.config.file}"/>

   Having a separate properties-file for each server type was helpful, because it made the deployment process agnostic of the type of server that we deployed to. The main property set in each of these files was deploy.tomcat or deploy.websphere (essentially deploy.server-type). Having these properties allowed us to configure the build-war macro according to the server type to handle the inclusion/exclusion of the JDBC 2.0 optional package (see Listing 1).

   Only one of the war-* targets is being called depending upon whether the deploy.websphere property is defined or not. This results in a macro definition of build-war, which has been configured for the target server.

   Similarly simply, the appropriate definitions for the security-* elements of the web.xml are handled according to the value of server.type.

   <!-- Copy the environment-specific version of the web-security.xml XDoclet merge file -->
   <target name="web-security-websphere" if="deploy.websphere">
   <copy file="${web.merge.dir}/was-web-security.xml"
   tofile="${web.merge.dir}/web-security.xml" overwrite="yes"/>
   </target>
   <target name="web-security-tomcat" unless="deploy.websphere">
   <copy file="${web.merge.dir}/tomcat-web-security.xml"
   tofile="${web.merge.dir}/web-security.xml" overwrite="yes"/>
   </target>

   The targets web-security-tomcat and web-security-websphere are then named as dependencies in other targets that use the XDoclet webdoclet task (which uses the web-security.xml deployment descriptor snippet).

   Listing 1: Ant macro for building a WAR file

   
   <!-- Call the build-war macro that is defined by the dependencies -->
   <target name="package-web"
        depends="webdoclet,war-tomcat,war-websphere">
     <build-war/>
   </target>
   
   <!-- Setup the build-war macro for a tomcat deploy -->
   <target name="war-tomcat" depends="" unless="deploy.websphere">
     <macrodef name="build-war">
       <sequential>
         <war destfile="${web.dist.dir}/${web.war}"
                webxml="${web.build.dir}/WEB-INF/web.xml"
              compress="true">
           <fileset dir="${web.build.dir}"    excludes="**/web.xml" />
           <webinf  dir="${struts.dir}"       includes="validator.xml,*.dtd" />
           <lib     dir="${cfmx.dir}"         includes="*.jar" />
           <lib     dir="${commons-lang.dir}" includes="*.jar" />
           <lib     dir="${dist.dir}"         includes="${dist.name}" />
           <lib     dir="${jstl.lib.dir}"     includes="*.jar" />
           <lib     dir="${struts.dir}"       includes="*.jar" />
           <lib    file="${commons-dbcp.jar}"/>
           <lib    file="${commons-pool.jar}"/>
           <lib    file="${log4j.jar}" />
           <lib    file="${spring.jar}" />
           <lib    file="${jdbc.jar}"/>
           <lib    file="${jtds.jar}"/>
         </war>
       </sequential>
     </macrodef>
   </target>
   
   <!-- Setup the build-war macro for a WebSphere deploy -->
   <target name="war-websphere" depends="" if="deploy.websphere">
     <macrodef name="build-war">
       <sequential>
         <war destfile="${web.dist.dir}/${web.war}"
                webxml="${web.build.dir}/WEB-INF/web.xml"
              compress="true">
           <fileset dir="${web.build.dir}"    excludes="**/web.xml" />
           <webinf  dir="${struts.dir}"       includes="validator.xml, *.dtd" />
           <lib     dir="${commons-lang.dir}" includes="*.jar" />
           <lib     dir="${dist.dir}"         includes="${dist.name}"/>
           <lib     dir="${jstl.lib.dir}"     includes="*.jar" />
           <lib     dir="${struts.dir}"       includes="*.jar" />
           <lib    file="${commons-dbcp.jar}"/>
           <lib    file="${commons-pool.jar}"/>
           <lib    file="${log4j.jar}" />
           <lib    file="${spring.jar}" />
           <lib    file="${jtds.jar}"/>
         </war>
       </sequential>
     </macrodef>
   </target>