Chapter 2   Architectural Configuration


iPlanet Trustbase Transaction Manager can be deployed over a variety of hardware configurations:

• It may be configured on single and clustered iPlanet Application Server installations

• It has a variety of configuration issues within the DMZ environment

• It can also be configured using Hardware Security Modules

iPlanet Application Server configuration

---

iPlanet Application Server may be used in a wide variety of configurations to support differing requirements for:

• Scalability

• Throughput

• Failover

The iPlanet Trustbase Transaction Manager has been designed to take advantage of these facilities and has been tested on two of the main configurations, these being:

• Single iPlanet Application Server

• Clustered iPlanet Application Servers

A single iPlanet Application Server is the most likely configuration option for low volume pre-operational Transaction Manager environment. This is considered a standard iPlanet Trustbase Transaction Manager installation and requires no specific configuration options other than those outlined in the iPlanet Application Server installation guide. The recommended settings for iPlanet Application Server are:

• Single KJS for each CPU on the host machine

• Minimum 8 and Maximum 64 Threads per KJS

The iPlanet Trustbase Transaction Manager is generally a CPU bound processing environment. This means that installing a greater number or faster CPU's will improve performance.

The iPlanet Trustbase Transaction Manager utilises Oracle databases extensively. Oracle itself is both CPU and disk intensive. If possible, Oracle should be located on a separate computer to the iPlanet Trustbase Transaction Manager installation.

Clustered iPlanet Application Server installations provide a means of improving Scalability, throughput and fail-over over a single iPlanet Application Server running the iPlanet Trustbase Transaction Manager. Prior to installing a clustered iPlanet Application Server the following items require consideration:

• Each Machine running iPlanet Application Server can have a nCipher HSM. This is a requirement for Identrus Compliance.

• A clustered iPlanet Application Server environment may provide slower response times in marginal loading conditions

  
  

  ---

  Note

  For further information about performance tuning and effective deployment consult: Oracle 8i Administrators Reference Manual Chapter 2 SQL tuning can also be found in the Oracle 8i programmers Guide Tuning Server Performance is discussed within the iPlanet Web Server 4.1 Administration Guide Application Deployment is discussed within the iPlanet Application Server 6.0 Administration and Deployment Guide

  ---

  
  

Using a DMZ

---

The general architectural model for deploying an iPlanet Trustbase Transaction Manager is to place the application server within a Demilitarised Zone (DMZ) created using a proxy machine between two firewalls. This configuration provides a means of ensuring that an outside user cannot directly access or modify the logic that forms the application in order to circumvent the authentication and authorisation requirements.

The DMZ primary firewall must offer two unauthorised open ports to support SSL access and SMTP access. These ports are generally:

• SSL - Port 443

• SMTP - Port 25

Behind this firewall is a single machine that runs the SSL proxy, the SMTP listener, and the iPlanet Web Server. The secondary firewall has three ports open configured for the DMZ machine only. These three ports are:

• iPlanet Application Server Directory Port 389

• iPlanet Web Server
  • HTTP - Port 80

  • Admin - Port 8888

• Oracle

  
  

  ---

  Note	Oracle uses many ports. Consult your Oracle DBA about this.

  ---

  
  

The HTTP port is used by the SSL and SMTP proxies to communicate to the iPlanet Web Server located behind the secondary firewall. Both the SSL and SMTP listeners use the Oracle port to store information about connections as well as receive their configuration. The architecture is shown below.

Figure 2-1    DMZ Architecture

Using this configuration the systems administrators may use the HTML based configuration screens without the need for SSL certificates. This does not circumvent the authentication mechanisms as the configuration management mechanisms are authenticated using a Username and Password based authentication mechanism.

---

Note	The default configuration is such that it all runs on one machine. When you install iPlanet Application Server 6.0 and iPlanet Web Server 4.1 it installs a directory server that has a default port of 389 and an administrator port of 8888.

---

Machine Installations

---

In some instances it may be necessary to install product component software on different machines. The following table summarises possible combinations:

Table 2-1    Acceptable Machine Installations

Product Component to be separated	Separate Machine Installation?	Considerations
iTTM separated from IAS	Not Possible	If IAS and IWS are installed on Separate machines make sure iTTM is installed with IAS
IWS separated from IAS	Yes	See Section on Configurator Plug-in http://docs.iplanet.com/docs/manuals/ias.html
Oracle separated from iTTM	Yes	See Section "Oracle Database Configuration," on page 79
SSL Proxy separated from iTTM	Yes	See Section "Configuring the SSLproxy Separately"
SMTP Proxy separated from iTTM	Yes	See "Configuring the SMTP Proxy Separately"
IAS with other Web Servers	Not Supported

Configuring the SSLproxy Separately

---

In some situations it may be more convenient to place the SSLproxy on a separate machine.

Figure 2-2    DMZ Architecture for separating the SSLProxy

Using this configuration the systems administrators need to do the following.Configure nCipher Security world so that the nCipher boxes share the nCipher security world. A separate script is needed to ensure the appropriate iPlanet Trustbase Transaction Manager software is on both machines by performing the following steps:

1. Create a tar of a completed single machine install by typing tar -cvf Trustbase.tar Trustbase from the installation directory (/app)

2. Unpack this tar file on the computer you wish to run the proxy on. Unpack it into the same install directory structure as the original computer. (e.g /app). Do not install iPlanet Trustbase Transaction Manager, iPlanet Web Server or iPlanet Application Server on this new machine.

3. Enter the directory <new_install directory>/TTM and rename the directory that is named after the hostname of the computer and ensure it is the same as the new host. If the <new_install_directory> is different, edit the file <new_install_directory>/TTM/Scripts.setenv and change the directories names in TBASE_INSTALL and TBASE_HOME to refer to the <new_install_directory>

4. To start the proxy on its own, enter this new hostname directory <new_install directory>/TTM/Scripts. Run the ./runsslproxy script.

5. On the host that is now no longer running the ssl proxy, edit the script in <install directory>/TTM/Scripts entitled ./starttbase and remove the reference to the SSL Proxy. You will want to do the same with the ./stoptbase script.

It is not necessary to change the configuration settings from within the administration console since the proxy communicates with iPlanet Trustbase Transaction Manager and not the other way round. The transaction Co-ordinator field AIA for all certificates of all end users must also point to this new host of the SSLProxy.

Configuring the SMTP Proxy Separately

---

In some situations it may be more convenient to place the SMTP proxy on a separate machine.

Figure 2-3    DMZ Architecture for separating the SMTP Proxy

Using this configuration the systems administrators need to do the following.Configure nCipher Security world so that the nCipher boxes share the nCipher security world. A separate script is needed to ensure the appropriate iPlanet Trustbase Transaction Manager software is on both machines by performing the following steps:

1. Create a tar of a completed single machine install by typing tar -cvf Trustbase.tar Trustbase from the installation directory (/app)

2. Unpack this tar file on the computer you wish to run the proxy on. Unpack it into the same install directory structure as the original computer. (e.g /app). Do not install iPlanet Trustbase Transaction Manager, iPlanet Web Server or iPlanet Application Server on this new machine.

3. Enter the directory <new_install directory>/TTM and rename the directory that is named after the hostname of the computer and ensure it is the same as the new host. If the <new_install_directory> is different, edit the file <new_install_directory>/TTM/Scripts.setenv and change the directories names in TBASE_INSTALL and TBASE_HOME to refer to the <new_install_directory>

4. Edit the script <new_install_directory>/TTM/Scripts/runsmtpproxy to change the localhost to the machine hostname where iPlanet Trustbase Transaction Manager has been installed, as illustrated below:

   #!/bin/sh . ./setcp ulimit -n 128 echo $$ > pids/runsmtpproxy.pid cd $TBASE_INSTALL exec java uk.co.jcp.tbaseimpl.smtp.server.SmtpServer -debug 6 -url http://hailstorm.uk.sun.com/NASApp/TbaseSmime/SmimeServlet -timeout 120000

5. To start the proxy on its own, enter this new hostname directory <new_install directory>/TTM/Scripts. Run the ./runsmtpproxy script.

6. On the host that is now no longer running the SMTP proxy, edit the script in <install directory>/TTM/Scripts entitled ./starttbase and remove the reference to the SMTP Proxy. You will want to do the same with the ./stoptbase script.