bea.com | products | dev2dev | support | askBEA

Download Docs | Site Map | Glossary
Search

Using Web Server Plug-Ins With WebLogic Server

Installing and Configuring the Apache HTTP Server Plug-In

The following sections describe how to install and configure the Apache HTTP Server Plug-In:

- Overview of the Apache HTTP Server Plug-In

- Certifications

- Installing the Apache HTTP Server Plug-In

- Configuring the Apache HTTP Server Plug-In

- Template for the Apache HTTP Server httpd.conf File

- Sample httpd.conf Configuration Files

- Using SSL with the Apache Plug-In

- Issues with SSL-Apache Configuration

- Connection Errors and Clustering Failover

Overview of the Apache HTTP Server Plug-In

The Apache HTTP Server Plug-In allows requests to be proxied from an Apache HTTP Server to WebLogic Server. The plug-in enhances an Apache installation by allowing WebLogic Server to handle those requests that require the dynamic functionality of WebLogic Server.

The plug-in is intended for use in an environment where an Apache Server serves static pages, and another part of the document tree (dynamic pages best generated by HTTP Servlets or JavaServer Pages) is delegated to WebLogic Server, which may be operating in a different process, possibly on a different host. To the end user—the browser—the HTTP requests delegated to WebLogic Server still appear to be coming from the same source.

HTTP-tunneling, a technique which allows HTTP requests and responses access through a company's firewall, can also operate through the plug-in, providing non-browser clients access to WebLogic Server services.

The Apache HTTP Server Plug-In operates as an Apache module within an Apache HTTP Server. An Apache module is loaded by Apache Server at startup, and then certain HTTP requests are delegated to it. Apache modules are similar to HTTP servlets, except that an Apache module is written in code native to the platform.

Limitations in Apache Version 1.3.x

Version 1.3x of the Apache HTTP Server has several limitations with the WebLogic Server plug-in that do not exist in later versions.

Keep-Alive Connections Not Supported

Version 1.3.x of the Apache HTTP Server Plug-In creates a socket for each request and closes the socket after reading the response. Because Apache HTTP Server is multiprocessed, connection pooling and keep-alive connections between WebLogic Server and the Apache HTTP Server Plug-In cannot be supported.

Inconsistent States

The Apache HTTP Server has a multi-process architecture, and the state of the plug-in cannot be synchronized across multiple child processes. The following types of problems may occur:

- In a clustered environment, a plug-in may dispatch requests to an unavailable WebLogic Server instance because the DynamicServerList is not current in all plug-in processes.

- In non-clustered environment, a plug-in may lose the stickiness of a session created after restarting WebLogic Server instances, because some plug-in processes do not have the new JVMID of those restarted servers, and treat them as unknown JVMIDs.

To temporarily correct inconsistencies of this type, restart or send a HUP signal (kill -HUP) to the Apache server to refresh all plug-in processes.

To avoid these issues, upgrade to Apache 2.0.x, and configure Apache to use the multi-threaded and single-process model by setting MaxSpareServers=1 in httpd.conf. For information about editing httpd.conf, see Configuring the Apache HTTP Server Plug-In.

Keep-Alive Connections in Apache Version 2.0

Version 2.0 of the Apache HTTP Server Plug-In improves performance by using a reusable pool of connections from the plug-in to WebLogic Server. The plug-in implements HTTP 1.1 keep-alive connections between the plug-in and WebLogic Server by reusing the same connection in the pool for subsequent requests from the same client. If the connection is inactive for more than 30 seconds, (or a user-defined amount of time) the connection is closed and returned to the pool. You can disable this feature if desired. For more information, see "KeepAliveEnabled".

Proxying Requests

The plug-in proxies requests to WebLogic Server based on a configuration that you specify. You can proxy requests based on the URL of the request (or a portion of the URL). This is called proxying by path. You can also proxy requests based on the MIME type of the requested file. Or you can use a combination of both methods. If a request matches both criteria, the request is proxied by path. You can also specify additional parameters for each type of request that define additional behavior of the plug-in. For more information, see Configuring the Apache HTTP Server Plug-In.

Certifications

The Apache HTTP Server Plug-In is supported on Linux, Solaris, AIX, Windows, and HPUX11 platforms. Plug-ins are not supported on all operating systems for all releases.For information on platform support for specific versions of Apache, see Platform Support for WebLogic Server Plug-ins and Web Servers in Supported Configurations for WebLogic Server 7.0.

Installing the Apache HTTP Server Plug-In

You install the Apache HTTP Server Plug-In as an Apache module in your Apache HTTP Server installation. The module is installed either as a Dynamic Shared Object (DSO) or as a statically linked module. (Installation as a statically linked module is only available for Apache version 1.3.x). There are separate instructions in this section for DSO and statically linked module installation.

Installing the Apache HTTP Server Plug-In as a Dynamic Shared Object

To install the Apache HTTP Server Plug-In as a dynamic shared object:

1. Locate the shared object file for your platform.

   The Apache plug-in is distributed as a shared object (.so) for use on Solaris, Linux, Windows, AIX and HPUX11 platforms. Each shared object file is distributed as a separate version, depending on the platform, whether or not SSL is to be used between the client and Apache, and the encryption strength for SSL (regular or 128 bit— 128 bit versions are only installed if you install the 128 bit version of WebLogic Server). The shared object files are located in the following directories of your WebLogic Server installation (where WL_HOME is the top-level installation directory for the WebLogic platform and the Server directory contains WebLogic Server installation files):

   Table 2-1 Locations of Plug-In Shared Object Files

   Operating System | Shared Object Location
   --- | ---
   Solaris | WL_HOME/server/lib/solaris
   Linux | WL_HOME/server/lib/linux/i686 WL_HOME/server/lib/linux/s390
   Windows | WL_HOME\server\bin\mod_wl_20.so (applicable to Apache versions 2.0.x ) WL_HOME\server\bin
   HPUX11 | WL_HOME/server/lib/hpux11
   AIX | WL_HOME/server/lib/aix

   Warning: If you are running Apache 2.0.x server on HP-UX11, set the environment variables specified below before you build the Apache server. Because of a problem with the order in which linked libraries are loaded on HP-UX, a core dump can result if the load order is not preset as an environment variable before building. Set the following environment variables:

   >     export EXTRA_LDFLAGS="-lstd -lstream -lCsup -lm -lcl -ldld -lpthread"

     Proceed with the configure, make, and make install steps:

   >     ./configure --prefix=$INSTALLATION_DIRECTORY --enable-so --with-mpm=worker

   >     make

   >     make install

     See the Apache HTTP Server documentation for more information about building and configuring your Apache server.

   Choose the appropriate shared object from the following table:

   Apache Version | Regular Strength Encryption | 128-bit Encryption
   --- | --- | ---
   Standard Apache Version 1.x | mod_wl.so | mod_wl128.so
   Apache w/ SSL/EAPI Version 1.x (Stronghold, modssl etc.) | mod_wl_ssl.so | mod_wl128_ssl.so
   Apache + Raven Version 1.x Required because Raven applies frontpage patches that makes the plug-in incompatible with the standard shared object | mod_wl_ssl_raven.so | mod_wl128_ssl_raven.so
   Standard Apache Version 2.0.x | mod_wl_20.so | mod_wl28_20.so

2. Enable the shared object.

   The Apache HTTP Server Plug-In will be installed in your Apache HTTP Server installation as an Apache Dynamic Shared Object (DSO). DSO support in Apache is based on a module named mod_so.c that must be enabled before mod_wl.so is loaded. If you installed Apache using the supplied script, mod_so.c should already be enabled. To verify that mod_so.c is enabled, execute one of the following commands:

   >     For Apache 1.x, APACHE_HOME\bin\httpd -l

   >     For Apache 2.0.x, APACHE_HOME\bin\Apache -l

   (Where APACHE_HOME is the directory containing your Apache HTTP Server installation.)

   This command lists all of the enabled modules. If mod_so.c is not listed, build your Apache HTTP Server from the source code, making sure that the following options are configured:

   ...
   --enable-module=so
   --enable-rule=SHARED_CORE
   ...

3. Install the Apache HTTP Server Plug-In in the Apache 1.x server with a support program called apxs (APache eXtenSion, see Manual Page: apxs at http://httpd.apache.org/docs/programs/apxs.html). Issue the following command :

   >     $ apxs mod_so.c

   to build Dynamic Shared Object-based modules outside of the Apache source tree and add the following line to the httpd.conf file:

   >     AddModule mod_so.c

   For Apache 2.0.x, copy the mod_wl_20.so file to the APACHE_HOME\modules directory rather than running apxs. For more information, see the Apache HTTP Server Version 2.0 documentation.

4. Activate the weblogic_module, the WebLogic Server extension to the Apache server:

   - For Apache 1.x, in your WebLogic Server installation, use a command shell to navigate to the directory that contains the shared object for your platform and activate the weblogic_module by issuing this command (note that you must have Perl installed to run this Perl script):

     >     perl APACHE_HOME\bin\apxs -i -a -n weblogic mod_wl.so

     This command copies the mod_wl.so file to the APACHE_HOME\libexec directory. It also adds two lines of instructions for weblogic_module to the httpd.conf file and activates the module. Make sure that the following lines were added to your APACHE_HOME/conf/httpd.conf file in your Apache 1.x server installation:

     >     LoadModule weblogic_module         libexec/mod_wl.so
     >     AddModule mod_weblogic.c

   - For Apache 2.0.x, add the following line to your APACHE_HOME/conf/httpd.conf file manually:

     >     LoadModule weblogic_module     modules/mod_wl_20.so

5. Configure any additional parameters in the Apache httpd.conf configuration file as described in the section Configuring the Apache HTTP Server Plug-In. The httpd.conf file allows you to customize the behavior of the Apache HTTP Server Plug-In.

6. Verify the syntax of the APACHE_HOME\conf\httpd.conf file with one of the following commands:

   >     For Apache 1.x, APACHE_HOME\bin\apachect1 configtest

   >     For Apache 2.0.x, APACHE_HOME\bin\Apache -t

   The output of this command indicates any errors in your httpd.conf file.

Note: Apache -t is a valid command for Apache 2.0.x on Windows. However, for Apache 2.0.x on HP-UX, Apache -t is not a valid command, because Apache 2.0.x on HP-UX has apachectl and not the Apache command file.

1. Restart Weblogic Server.

2. Start (or restart if you have changed the configuration) Apache HTTP Server.

3. Test the Apache plug-in by opening a browser and setting the URL to the Apache Server + "/weblogic/", which should bring up the default WebLogic Server HTML page, welcome file, or default servlet, as defined for the default Web Application on WebLogic Server. For example:

   >     http://myApacheserver.com/weblogic/

Installing the Apache HTTP Server Plug-In as a Statically Linked Module

To install the Apache HTTP Server Plug-In as a statically linked module:

1. Locate the linked library file for your platform.

   Each library file is distributed as a separate version, depending on the platform and the encryption strength for SSL (regular or 128-bit—128-bit versions are only installed if you install the 128-bit version of WebLogic Server). The library files are located in the following directories of your WebLogic Server installation:

     Solaris

     WL_HOME/Server/lib/solaris

     Linux

     WL_HOME/Server/lib/linux

     HPUX11

     WL_HOME/Server/lib/hpux11

   Choose the appropriate shared object from the following table.

   Apache Version | Regular Strength Encryption | 128-bit Encryption
   --- | --- | ---
   Standard Apache Version 1.3.x | libweblogic.a | libweblogic128.a

   If you are using the Gnu C Compiler (gcc), gcc 2.95.x is the required version.

2. Unpack the Apache Plug-In distribution using the following command:

   >     tar -xvf apache_1.3.x.tar

3. Within the unpacked distribution switch to the src/modules directory.

4. Create a directory called weblogic.

5. Copy Makefile.libdir, Makefile.tmpl from the lib directory of your WebLogic Server installation to src\modules\weblogic.

6. Copy libweblogic.a (use libweblogic128.a instead, if you are using 128 bit security.) from the same directory containing the linked library file (see step 1. ) to src\modules\weblogic.

7. If you are using regular strength encryption, execute the following command from the Apache 1.3 home directory:

   >     configure --activate-module=src\modules\weblogic\libweblogic.a

8. If you are using 128 bit encryption, execute the following command (on a single line) from the Apache 1.3 home directory:

   >     configure--activate-module=
   >      src\modules\weblogic\libweblogic128.a

9. Execute the following command:

   >     make

10. Execute the following command:

    >     make install

11. Follow steps 4 through 8, inInstalling the Apache HTTP Server Plug-In as a Dynamic Shared Object

Configuring the Apache HTTP Server Plug-In

After you install the plug-in in the Apache HTTP server, edit the httpd.conf file to configure the Apache plug-in. Editing the httpd.conf file informs the Apache Web server that it should load the native library for the plug-in as an Apache module and also describes which requests should be handled by the module.

Editing the httpd.conf File

Edit the httpd.conf file in your Apache HTTP server installation to configure the Apache HTTP Server Plug-In:

1. Open the httpd.conf file. The file is located at APACHE_HOME\conf\httpd.conf (where APACHE_HOME is the root directory of your Apache HTTP server installation).

2. For Apache 1.x, verify that the following two lines were added to the httpd.conf file when you ran the apxs utility:

   >     LoadModule weblogic_module    libexec\mod_wl.so
   >     AddModule mod_weblogic.c

3. For Apache 2.0.x, add the following line to the httpd.conf file:

   >     LoadModule weblogic_module   modules\mod_wl_20.so

4. Add an IfModule block that defines one of the following:

   For a non-clustered WebLogic Server:

   The WebLogicHost and WebLogicPort parameters.

   For a cluster of WebLogic Servers:

   The WebLogicCluster parameter.

   For example:

   >     <IfModule mod_weblogic.c>
   >       WebLogicHost myweblogic.server.com
   >       WebLogicPort 7001
   >     </IfModule>

5. If you want to proxy requests by MIME type, also add a MatchExpression line to the IfModule block. (You can proxy requests by path in addition to or instead of proxying by MIME type. Proxying by path takes precedence over proxying by MIME type. To configure proxying requests by path, see step 6. )

   For example, the following IfModule block for a non-clustered WebLogic Server specifies that all files with MIME type .jsp are proxied:

   >     <IfModule mod_weblogic.c>
   >       WebLogicHost myweblogic.server.com
   >       WebLogicPort 7001
   >       MatchExpression *.jsp
   >     </IfModule>

   You can also use multiple MatchExpressions, for example:

   >     <IfModule mod_weblogic.c>
   >       WebLogicHost myweblogic.server.com
   >       WebLogicPort 7001
   >       MatchExpression *.jsp
   >       MatchExpression *.xyz
   >     </IfModule>

   If you are proxying requests by MIME type to a cluster of WebLogic Servers, use the WebLogicCluster parameter instead of the WebLogicHost and WebLogicPort parameters. For example:

   >     <IfModule mod_weblogic.c>
   >       WebLogicCluster w1s1.com:7001,w1s2.com:7001,w1s3.com:7001
   >       MatchExpression *.jsp
   >       MatchExpression *.xyz
   >     </IfModule>

6. If you want to proxy requests by path, use the Location block and the SetHandler statement. SetHandler specifies the handler for the Apache HTTP Server Plug-In module. For example the following Location block proxies all requests containing /weblogic in the URL:

   >     <Location /weblogic>
   >       SetHandler weblogic-handler
   >     </Location>

7. Define any additional parameters for the Apache HTTP Server Plug-In.

   The Apache HTTP Server Plug-In recognizes the parameters listed in General Parameters for Web Server Plug-Ins. To modify the behavior of your Apache HTTP Server Plug-In, define these parameters either:

   - In a Location block, for parameters that apply to proxying by path, or

   - In an IfModule block, for parameters that apply to proxying by MIME type.

Alternative Procedure for Editing the httpd.conf File

- As an alternative to the procedure in Editing the httpd.conf File you can define parameters in a separate file called weblogic.conf file that is included in the IfModule block. Using this included file may help modularize your configuration. For example:

  >     <IfModule mod_weblogic.c>
  >       # Config file for WebLogic Server that defines the parameters
  >       Include conf/weblogic.conf
  >     </IfModule>

  Note: Defining parameters in an included file is not supported when using SSL between Apache HTTP Server Plug-In and WebLogic Server.

- Enter each parameter on a new line. Do not put an `=' between the parameter and its value. For example:

  >     PARAM_1 value1
  >     PARAM_2 value2
  >     PARAM_3 value3

- If a request matches both a MIME type specified in a MatchExpression in an IfModule block and a path specified in a Location block, the behavior specified by the Location block takes precedence.

- If you define the CookieName parameter, you must define it in an IfModule block.

- If you use the <files> block in addition to the <location> block to match requests and you are using Stronghold SSL (a commercial Apache-based Web server) with virtual hosting, MatchExpression is ignored and the rules defined in the <files> and <location> blocks are applied to the request. If you are not using Stronghold, rules in the <location> block overrule those in a <files> block.

- If you use the <VirtualHost> block, you must place all the configuration parameters (MatchExpression, for example) for each virtual host within its <VirtualHost> block.

- If you want to have only one log file for all the virtual hosts configured in your environment, you can achieve it using global properties. Instead of specifying the same Debug, WLLogFile and WLTempDir properties in each virtual host you can specify them just once in the <IfModule> tag

- Sample httpd.conf file:

>     <IfModule mod_weblogic.c>

>       WebLogicCluster	agarwalp02:8005,agarwalp02:8006

>       Debug 		ON

>       WLLogFile             c:/tmp/global_proxy.log

>       WLTempDir             "c:/myTemp"

>       DebugConfigInfo       On

>       KeepAliveEnabled ON

>       KeepAliveSecs  15

>     </IfModule>

>     <Location /jurl>

>       SetHandler weblogic-handler

>       WebLogicCluster agarwalp01:7001

>     </Location>

>     <Location /web>

>       SetHandler weblogic-handler

>       PathTrim		/web

>       Debug 		OFF

>       WLLogFile 		c:/tmp/web_log.log

>     </Location>

>     <Location /foo>

>       SetHandler weblogic-handler

>       PathTrim		/foo

>       Debug 		ERR

>       WLLogFile 		c:/tmp/foo_proxy.log

>     </Location>

All the requests which match /jurl/* will have Debug Level set to ALL and log messages will be logged to c:/tmp/global_proxy.log file. All the requests which match /web/* will have Debug Level set to OFF and no log messages will be logged. All the requests which match /foo/* will have Debug Level set to ERR and log messages will be logged to c:/tmp/foo_proxy.log file

- BEA recommends that you use the MatchExpression statement instead of the <files> block.

Template for the Apache HTTP Server httpd.conf File

This section contains a sample httpd.conf file. You can use this sample as a template that you can modify to suit your environment and server. Lines beginning with # are comments. Note that Apache HTTP Server is not case sensitive, and that the LoadModule and AddModule lines are automatically added by the apxs utility.

>     ####################################################

>     APACHE-HOME/conf/httpd.conf file
>     ####################################################

>     LoadModule weblogic_module   libexec/mod_wl.so

>     AddModule mod_weblogic.c

>     <Location /weblogic>
>       SetHandler weblogic-handler
>       PathTrim /weblogic
>       ErrorPage http://myerrorpage1.mydomain.com
>     </Location>

>     <Location /servletimages>
>       SetHandler weblogic-handler
>       PathTrim /something
>       ErrorPage http://myerrorpage1.mydomain.com
>     </Location>

>     <IfModule mod_weblogic.c>
>       MatchExpression *.jsp
>       WebLogicCluster w1s1.com:7001,w1s2.com:7001,w1s3.com:7001
>       ErrorPage http://myerrorpage.mydomain.com
>     </IfModule>

Sample httpd.conf Configuration Files

Instead of defining parameters in the location block of your httpd.conf file, if you prefer, you can use a weblogic.conf file that is loaded by the IfModule in the httpd.conf file. The following examples may be used as templates that you can modify to suit your environment and server. Lines beginning with # are comments.

Example Using WebLogic Clusters

>     # These parameters are common for all URLs which are
>     # directed to the current module. If you want to override
>     # these parameters for each URL, you can set them again in
>     # the <Location> or <Files> blocks. (Except WebLogicHost,
>     # WebLogicPort, WebLogicCluster, and CookieName.)

>     <IfModule mod_weblogic.c>
>       WebLogicCluster w1s1.com:7001,w1s2.com:7001,w1s3.com:7001
>       ErrorPage http://myerrorpage.mydomain.com
>       MatchExpression *.jsp
>     </IfModule>
>     ####################################################

Example Using Multiple WebLogic Clusters

>     # These parameters are common for all URLs which are
>     # directed to the current module. If you want to override
>     # these parameters for each URL, you can set them again in
>     # the <Location> or <Files> blocks (Except WebLogicHost,
>     # WebLogicPort, WebLogicCluster, and CookieName.)

>     <IfModule mod_weblogic.c>
>       MatchExpression *.jsp WebLogicHost=myHost|WebLogicPort=7001|Debug=ON
>       MatchExpression *.html WebLogicCluster=myHost1:7282,myHost2:7283|ErrorPage=
>         http://www.xyz.com/error.html
>     </IfModule>

Example Without WebLogic Clusters

>     # These parameters are common for all URLs which are
>     # directed to the current module. If you want to override
>     # these parameters for each URL, you can set them again in
>     # the <Location> or <Files> blocks (Except WebLogicHost,
>     # WebLogicPort, WebLogicCluster, and CookieName.)

>     <IfModule mod_weblogic.c>
>       WebLogicHost myweblogic.server.com
>       WebLogicPort 7001
>       MatchExpression *.jsp
>     </IfModule>

Example Configuring IP-Based Virtual Hosting

>     NameVirtualHost 172.17.8.1
>     <VirtualHost goldengate.domain1.com>
>     WebLogicCluster tehama1:4736,tehama2:4736,tehama:4736
>     PathTrim /x1
>     ConnectTimeoutSecs 30
>     </VirtualHost>
>     <VirtualHost goldengate.domain2.com>
>     WeblogicCluster green1:4736,green2:4736,green3:4736
>     PathTrim /y1
>     ConnectTimeoutSecs 20
>     </VirtualHost>

Example Configuring Name-Based Virtual Hosting With a Single IP Address

>     <VirtualHost 162.99.55.208>
>             ServerName myserver.mydomain.com
>              <Location / >
>                    SetHandler weblogic-handler
>                    WebLogicCluster 162.99.55.71:7001,162.99.55.72:7001
>                    Idempotent ON
>                    Debug ON
>                    DebugConfigInfo ON
>             </Location>
>     </VirtualHost>

>     <VirtualHost 162.99.55.208>
>             ServerName myserver.mydomain.com
>            <Location / >
>                     SetHandler weblogic-handler
>                     WebLogicHost russell
>                     WebLogicPort 7001
>                     Debug ON
>                     DebugConfigInfo ON
>             </Location>
>     </VirtualHost>

Example Configuring Multiple Name-Based Virtual Hosts

>     # VirtualHost1 = localhost:80
>     <VirtualHost 127.0.0.1:80>
>     	DocumentRoot "C:/test/VirtualHost1"
>     	ServerName localhost:80	<IfModule mod_weblogic.c>
>     	#... WLS parameter ...
>     	WebLogicCluster localhost:7101,localhost:7201
>     	# Example: MatchExpression *.jsp <some additional parameter>
>     	MatchExpression *.jsp PathPrepend=/test2
>     	</IfModule>
>     </VirtualHost>

>     # VirtualHost2 = 127.0.0.2:80
>     <VirtualHost 127.0.0.2:80>
>     	DocumentRoot "C:/test/VirtualHost1"
>     	ServerName 127.0.0.2:80
>     	<IfModule mod_weblogic.c>
>     	#... WLS parameter ...
>     	WebLogicCluster localhost:7101,localhost:7201
>     	# Example: MatchExpression *.jsp <some additional parameter>
>     	MatchExpression *.jsp PathPrepend=/test2
>     	#... WLS parameter ...
>     	</IfModule>
>     </VirtualHost>	<IfModule mod_weblogic.c>

You must define a unique value for 'ServerName'or some Plug-In parameters will not work as expected.

Using SSL with the Apache Plug-In

You can use the Secure Sockets Layer (SSL) protocol to protect the connection between the Apache HTTP Server Plug-In and WebLogic Server. The SSL protocol provides confidentiality and integrity to the data passed between the Apache HTTP Server Plug-In and WebLogic Server.

The Apache HTTP Server Plug-In does not use the transport protocol (http or https) specified in the HTTP request (usually by the browser) to determine whether or not the SSL protocol is used to protect the connection between the Apache HTTP Server Plug-In and WebLogic Server.

Although two-way SSL can be used between the HTTP client and Apache HTTP server, note that one-way SSL is used between Apache HTTP Server and WebLogic Server.

Implementing Two-way SSL between Apache and the HTTP Client:

1. Configure Apache HTTP Server to request a client certificate. The certificate is stored as one of the following request attributes:

   - javax.net.ssl.peer_certificates

     returns a weblogic.security.X509Certificate certificate

   - java.security.cert.X509Certificate

     returns a java.security.cert.X509 certificate

2. Access the certificate by reading the request attribute, for example:

   >     request.getAttribute("javax.net.ssl.peer_certificates");

3. In WebLogic Server, authenticate the user with the weblogic.security.acl.certAuthenticator.authenticate() method.

Configuring SSL Between the Apache HTTP Server Plug-In and WebLogic Server

To use the SSL protocol between Apache HTTP Server Plug-In and WebLogic Server:

1. Configure WebLogic Server for SSL. For more information, see Configuring the SSL Protocol.

2. Configure the WebLogic Server SSL listen port. For more information, see Configuring the SSL Protocol.

3. In the Apache Server, set the WebLogicPort parameter in the httpd.conf file to the listen port configured in step 2.

4. In the Apache Server, set the SecureProxy parameter in the httpd.conf file to ON.

5. Set any additional parameters in the httpd.conf file that define information about the SSL connection. For a complete list of parameters, see SSL Parameters for Web Server Plug-Ins

Specifying Trust for the WL-Proxy-Client-Cert Header

The plug-in can encode users' identity certifications in the WL-Proxy-Client-Cert header and pass the header to WebLogic Server instances (see Proxying Requests to Another Web Server). A WebLogic Server instance uses the certificate information from that header, trusting that it comes from a secure source (the Plug-In), to authenticate the user. In previous releases of WebLogic Server, the default behavior was to always trust the WL-Proxy-Client-Cert header. Beginning with WebLogic Server 6.1 SP2, you need to explicitly define trust of the WL-Proxy-Client-Cert header. A new parameter, clientCertProxy, allows WebLogic Server to determine whether to trust the certificate header. For an additional level of security, use a connection filter to limit all connections into WebLogic Server (therefore allowing WebLogic Server to only accept connections from the machine on which the plug-in is running).

The clientCertProxy parameter has been added to the HTTPClusterServlet and Web applications.

For the HTTPClusterServlet, add the parameter to the web.xml file as follows:

>     <context-param>

>             <param-name>clientCertProxy</param-name>

>             <param-value>true</param-value>

>     </context-param>

For Web applications, add the parameter to the web.xml file as follows:

>     ServletRequestImpl context-param

>     <context-param>

>             <param-name>weblogic.httpd.clientCertProxy</param-name>

>             <param-value>true</param-value>

>     </context-param>

You can also use this parameter in a cluster as follows:

>     <Cluster ClusterAddress="127.0.0.1" Name="MyCluster"

>             ClientCertProxyHeader="true"/>

This parameter can be used with a third party proxy server such as a load balancer or an SSL accelerator to enable 2-way SSL authentication.

Issues with SSL-Apache Configuration

The following known issues may arise when you configure the Apache plug-in to use SSL:

- To prepare the plugin configuration, double click the lock and go to the certificates path:

  * Select the root CA (at the top)

  * Display it

  * Detail and then copy this certificate to a file using the Coded "Base

  64 X509" option

  * Save the file, for example, to ýMyWeblogicCAToTrust.cerý (which is also a PEM file)

- The PathTrim parameter must be configured inside the <Location> tag.

  The following configuration is incorrect:

  >     <Location /weblogic>
  >      SetHandler weblogic-handler
  >     </Location>

  >     <IfModule mod_weblogic.c>
  >      WebLogicHost localhost
  >      WebLogicPort 7001
  >      PathTrim /weblogic
  >     </IfModule>

  The following configuration is the correct setup:

  >     <Location /weblogic>
  >       SetHandler weblogic-handler
  >       PathTrim /weblogic
  >     </Location>

- The Include directive does not work with Apache SSL. You must configure all parameters directly in the httpd.conf file. Do not use the following configuration when using SSL:

  >     <IfModule mod_weblogic.c>
  >       MatchExpression *.jsp
  >       Include weblogic.conf
  >     </IfModule>

- If you use precompiled OpenSSL from Sunfreeware.com, failover may not work properly when the plug-in tries to connect to a backend instance of WebLogic Server. If you encounter such a failure, rebuild OpenSSL and modssl and Apache using the following configuration settings.

  - For building OpenSSL:

    >     ./Configure solaris-sparcv8-gcc -fexceptions

    >     --prefix=/home/egross/solaris/ssl shared

    >     make

    >     make install

  - For building modssl and Apache:

    >     cd ..

    >     cd mod_ssl-2.8.12-1.3.27

    >     export LD_LIBRARY_PATH=/home/egross/solaris/ssl/lib

    >      ./configure "--with-apache=../apache_1.3.27"

    >     "--with-ssl=/home/egross/solaris/ssl" "--prefix=/usr/local/apache_so"

    >     "--enable-rule=SHARED_CORE" "--enable-shared=ssl" "--enable-module=so" "$@"

    >     cd ../apache_1.3.27

    >     make

    >     make install

- The current implementation of the WebLogic Server Apache plug-in does not support the use of multiple certificate files with ApacheSSL.

Connection Errors and Clustering Failover

When the Apache HTTP Server Plug-In attempts to connect to WebLogic Server, the plug-in uses several configuration parameters to determine how long to wait for connections to the WebLogic Server host and, after a connection is established, how long the plug-in waits for a response. If the plug-in cannot connect or does not receive a response, the plug-in attempts to connect and send the request to other WebLogic Server instances in the cluster. If the connection fails or there is no response from any WebLogic Server in the cluster, an error message is sent.

Figure 2-1 demonstrates how the plug-in handles failover.

Possible Causes of Connection Failures

Failure of the WebLogic Server host to respond to a connection request could indicate possible problems with the host machine, networking problems, or other server failures.

Failure of all WebLogic Server instances to respond, could indicate that WebLogic Server is not running or is unavailable, a hung server, a database problem, or other application failure.

Failover with a Single, Non-Clustered WebLogic Server

If you are running only a single WebLogic Server instance the plug-in only attempts to connect to the server defined with the WebLogicHost parameter. If the attempt fails, an HTTP 503 error message is returned. The plug-in continues trying to connect to that same WebLogic Server instance until ConnectTimeoutSecs is exceeded.

The Dynamic Server List

When you specify a list of WebLogic Servers in the WebLogicCluster parameter, the plug-in uses that list as a starting point for load balancing among the members of the cluster. After the first request is routed to one of these servers, a dynamic server list is returned containing an updated list of servers in the cluster. The updated list adds any new servers in the cluster and deletes any that are no longer part of the cluster or that have failed to respond to requests. This list is updated automatically with the HTTP response when a change in the cluster occurs.

Failover, Cookies, and HTTP Sessions

When a request contains a session information stored in a cookie, in the POST data, or by URL encoding, the session ID contains a reference to the specific server instance in which the session was originally established (called the primary server) and a reference to an additional server where the original session is replicated (called the secondary server). A request containing a cookie attempts to connect to the primary server. If that attempt fails, the request is routed to the secondary server. If both the primary and secondary servers fail, the session is lost and the plug-in attempts to make a fresh connection to another server in the dynamic cluster list. For more information, see Figure 2-1 Connection Failover.

Note: If the POST data is larger than 64K, the plug-in will not parse the POST data to obtain the session ID. Therefore, if you store the session ID in the POST data, the plug-in cannot route the request to the correct primary or secondary server, resulting in possible loss of session data.

Figure 2-1 Connection Failover

Notes: The HTTP error code thrown by the plug-in depends on the situation. Plug-in will return the HTTP error code 500 in the following conditions:

- Neither WebLogicCluster nor WebLogicPort was specified in the httpd.conf file.

- Unable to resolve the WebLogicHost parameter specified in the httpd.conf file.

- Port number specified by WebLogicPort, in the httpd.conf file, exceeds 65535.

- Unsuccessful in parsing the request while applying the PathTrim property.

- The request header is of type Unknown Transfer-Encoding.
  Failed to read the chunked request.

- Encounetered an error reading POST data from client.

- Failed to open a temporary(temp) file.

- Failed to write POST data to the temp file.

- Encounetered an error reading POST data from the temp file.

- POST timed out.

- SSL was specified without the parameter trustedCAFile.

On the other hand, the HTTP error code 503 is returned when:

- The maximum number of retries is exceeded. This value is computed by dividing ConnectTimeoutSecs by ConnectRetrySecs.

- Idempotent is OFF.