InfoCenter Home >
5: Securing applications -- special topics >
5.6: Establishing trust association with a reverse proxy server >
5.6.1: Configuring trust association between WebSphereApplication Server and WebSeal Version 3.6

5.6.1: Configuring trust association between WebSphere Application Server and WebSeal Version 3.6

To enable use of a trust association between WebSphere Application Server and WebSeal, you must perform configuration work for each of the following:

  • WebSphere Application Server
  • The interceptor for WebSeal (configuration is optional)
  • WebSeal
This file describes the configuration for each component and provides a sample configuration.

Configuring WebSphere Application Server to run in trust association

WebSphere Application Server must be configured to run in trust-assocation mode by setting up the trust-association interceptors that are going to receive HTTP requests from the trusted proxy server.

Create a file called named trustedservers.properties, and place the file in the product_installation_root /properties directory.

The trustedservers.properties file for WebSeal must include the following three lines and an optional fourth line:

com.ibm.websphere.security.trustassociation.enabled=true
com.ibm.websphere.security.trustassociation.types=webseal36
com.ibm.websphere.security.trustassociation.webseal36.interceptor=
com.ibm.ejs.security.web.WebSealTrustAssociationInterceptor
com.ibm.websphere.security.trustassociation.webseal36.config=webseal36
The following describes each of the property-value pairs:
  • com.ibm.websphere.security.trustassociation.enabled=true
    This property-value pair enables the use of trust assocation.
  • com.ibm.websphere.security.trustassociation.types=webseal36
    This property-value pair specifies the types of the servers with which you are establishing trust. If you are using multiple proxy servers, you can specify a comma-delimited list as the value.
  • com.ibm.websphere.security.trustassociation.webseal36.interceptor= com.ibm.ejs.security.web.WebSeal36TrustAssociationInterceptor
    This property-value pair specifies the name of the Java class implementing the interceptor for the proxy. When specifying this class, note the following:
    • The class must be locatable from the information on the class path.
    • You only need to specify the implementation class for an interceptor once, even if multiple proxy servers use the same implementation class for the interceptor.
  • com.ibm.websphere.security.trustassociation.webseal36.config=websea l36
    OPTIONAL. This property-value pair specifies a configuration file for the WebSeal36 interceptor. The contents of this file are described under "Configuring the WebSeal interceptor."
Each property-value pair must appear on a single line in the file. Pairs appearing on more than one line in this example have been broken for readability.

Configuring the WebSeal interceptor (optional)

WebSphere Application Server provides a Java class, com.ibm.ejs.security.web.WebSeal36TrustAssociationInterceptor, that implements the essential interceptor for enabling trust association between WebSeal 3.6 and WebSphere Application Server.

By default, the interceptor processes all HTTP requests it receives. You can configure the interceptor to restrict the requests that it processes locally. The restrictions can be specified by identifier, originating host, and originating port, and by combinations. This configuration is optional.

To configure the interceptor, create a property file for the optional configuration-file property, and place the file in the <product_installation_root> /properties directory. In this example, we create a file called webseal36.properties to correspond to the the optional property-value pair com.ibm.websphere.security.trustassociation.webseal36.config=webseal36 specified in the trustedservers.properties file.

Use this file to set properties restricting the requests that interceptor will process. The properties act as requirements on requests, and each request must meet all of the requirements. Requests not meeting all of the requirements are not processed by the interceptor; they are passed on to WebSphere Application Server for processing.

The file can set values for any of the following WebSeal properties, for example:
  • com.ibm.websphere.security.webseal36.id=iv-user, iv-creds
    This property-value pair tells the interceptor to filter incoming HTTP requests by identifier. The value is a comma-delimited list of identifiers. Every HTTP request is examined by the interceptor. Only those requests that contain all of the listed IDs as request-header names are be considered for processing by the interceptor. All other requests are passed on to WebSphere Application Server for processing in the usual way. By default, all HTTP requests are considered by the interceptor for processing.
    Because the WebSeal36 interceptor should process only HTTP requests from WebSeal, the recommended value for use with WebSphere Application Server sets this property to one or both of these values:
    • iv-user
    • iv-creds
    The example property-value pair uses both.
  • com.ibm.websphere.security.webseal36.hostnames= <hostname1>,<hostname2>
    This property-value pair specifies a list of names of the machines on which WebSeal servers run and from which the interceptor can accept HTTP requests. If this property is not set, the interceptor accepts requests from any host.
  • com.ibm.websphere.security.webseal36.ports=444
    This property-value pair specifies the ports from which HTTP requests must originate in order to be processed. Requests originating from other ports are ignored. The list applies to all hosts from which the interceptor accepts requests. There is no way to specify a list of ports for one host and a different list for a different host. If this property is not set, requests originating from any port are considered for processing.

Configuring WebSeal

The last step is to configure Tivoli's WebSeal product. This product is not part of WebSphere Application Server, so you should consult the WebSeal documentation for details and in case of problems.

To enable communication between WebSeal and WebSphere Application Server, the the Web server being used by WebSphere Application Server must become an SSL junction in the schema of the Tivoli Policy Director. If the Web server is using the default SSL port, port 443, create an SSL junction with the following junctioncp command:

create -c -t ssl -h <hostname> /<junction-name>
where
  • The -c flag directs WebSeal to pass its authentication information in the basic authentication header of every request that it sends to WebSphere Application Server. The authentication information is the user ID and password of the WebSeal server. This allows WebSphere Application Server to authenticate every request that it receives from the WebSeal server.
  • The -t ssl option requests the creation of junction of the type SSL.
  • The -h <hostname> option specifies the host machine of the Web server used by WebSphere Application Server.
For example, the command:
create -c -t ssl -h was_host.raleigh.ibm.com /myjunction
creates an SSL junction called myjunction for the machine was_host.raleigh.ibm.c om.

If the Web server is not listening to the default SSL port, port 443, use the port option to the junctioncp command to indicate the port being used:
-p <port_number>

The WebSeal server must have a user ID and password it can use when it authenticates to WebSphere Application Server. To set up this authentication information, you must do the following:

  1. Designate a ID from the WebSphere Application Server user registry for use by WebSeal. You can create a special WebSeal ID in WebSphere Application Server, or you can simply use an existing ID from the WebSphere Application Server registry.
  2. Put this user ID and associated password in the WebSeal configuration file, iv.conf. In this file, you must have the following:
    basic_auth_username=<userId >
    basic_auth_passwd=<password>
    where <userId> and <password> are valid account information from the WebSphere Application Server registry.

Because SSL is involved in the junction, you must ensure that the Web server being used by WebSphere Application Server is configured with SSL using server authentication only. In this configuration, WebSeal plays a client role. Therefore, you must copy the certificate of the issuing CA of the Web server into the WebSeal certificate directory.

Please consult the WebSeal Policy Director manual for detailed information on setting up SSL connections between WebSeal and a junction server. During the procedure, be sure to update the configuration file for the security manager, secmgrd.conf, to include the following line:
junction-ca-cert-file = <ca-certfile>
where <ca-certfile> is the aboslute path of the file containing the CA certificates of the junction servers, for example,

/opt/intraverse/lib/certs/junctioncacert.pem
. Without the line, basic authentication will not take place between WebSeal and WebSphere Application Server.

Finally, to access a resource through WebSeal, you need to use SSL. Therefore, you must ensure that WebSeal itself is configured for SSL.

Sample configuration

This section describes a sample configuration.

  • WebSphere Application Server is installed on the machine was_host.raleigh.ibm.com.
  • The Web server is Netscape Enterprise Server, also installed on the machine was_host.raleigh.ibm.com. The Web server is listening on port 4343 for SSL requests.
  • The LTPA security mechanism is used, with the LDAP server residing on the machine ldap_host.raleigh.ibm.com.
  • WebSeal is installed on the machine webseal_host.raleigh.ibm.com. It listens on port 444 for SSL requests.
  • A junction was created using the following command:
    junctioncp create -c -t ssl -h was_host.raleigh.ibm.com -p 4343 /myjunction
  • In the WebSeal iv.conf file, the following lines are included:
    basic_auth_username=web_user
    basic_auth_passwd=testpassword
    where the ID web_user with password testpassword is registered in the WebSphere Application Server registry.
  • In the Policy Director secmgrd.conf file, the following line is included:
    junction-ca-cert-file=/opt/intraverse/lib/certs/junctioncacert.pem
  • The ID testuser1 with password sherlock is a valid WebSeal user. It is also a valid WebSphere Application Server user.

A user tests the system by logging in as testuser1 and attempting access the WebSphere Application Server servlet /servlet/snoop:

  • To test access without WebSeal, the user enters the following in the Web browser:
    https://was_host.raleigh.ibm.com/servlet/snoop
  • To test access through WebSeal, the user enters the following:
    https://webseal_host.raleigh.ibm.com:444/aim/servlet/snoop
In both cases, a prompt is displayed in which the user enters the testuser1/sherlock combination and the snoop servlet is displayed on the Web browser.

Go to previous article: Establishing trust association with a reverse proxy server Go to next article: Frequently asked questions about trust association

 

 
Go to previous article: Establishing trust association with a reverse proxy server Go to next article: Frequently asked questions about trust association