Skip Headers
Oracle® Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service
11g Release 1 (11.1.1)

Part Number E15478-05
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

28 Configuring Apache, OHS, IHS for 10g Webgates

Oracle Access Manager provides Webgates for Web servers powered by Apache v2. This includes Apache, Oracle HTTP Server, and IBM HTTP Server (IHS).

This chapter provides details about configuring the three Web server types, and includes:

Prerequisites

Ensure that your Oracle Access Manager Console is running and get familiar with:

About Oracle HTTP Server and Oracle Access Manager

Oracle Access Manager Web component package names for Oracle HTTP Server are designated with OHS, as follows:

The following Oracle HTTP Server releases will operate with Oracle Access Manager:

Oracle HTTP Server 11g: Oracle Access Manager Webgates Oracle HTTP Server 11g can be used like Webgates for any other Web server. In addition, this Webgate for Oracle HTTP Server 11g is a key component when configuring enterprise-level single sign-on for Oracle Fusion Middleware 11g. For details, see the Oracle Fusion Middleware Security Guide. See also the Oracle Fusion Middleware Administrator's Guide for HTTP Server 11g Release 1 (11.1.1).

Oracle HTTP Server 10g (10.1.3.1.0): Provides two packages (one based on Apache v1.3 and another based on Apache v2.0). Webgates can be installed on a standalone Oracle HTTP Server. OHS2 Webgate must be installed on the Oracle Application Server to enable integration with Oracle single sign-on. During installation, the Webgate is installed as a module on OHS2.

Be sure to familiarize yourself with Oracle HTTP Server Web component requirements, as described in "Preparing Your Web Server".

About Oracle Access Manager with Apache and IHS v2 Webgates

Oracle Access Manager provides components for Apache v2 Web servers and the IBM HTTP Server in addition to the Oracle HTTP Server. The IBM HTTP Server (IHS2) is a variation of Apache v2. Unless otherwise stated, the following information applies to all three:

Each platform-specific installation package supports both plain and SSL-capable Apache modes. The number 2 in a file name indicates that this component is based on Apache v2. For example:

AIX: Oracle_Access_Manager10_1_4_3_0_power-aix_IHS2_Webgate

Linux: Oracle_Access_Manager10_1_4_3_0_ linux_Apache2_Webgate

Solaris: Oracle_Access_Manager10_1_4_3_0_sparc-s2_Apache2_Webgate

Windows: Oracle_Access_Manager10_1_4_3_0_Win32_APACHE2_Webgate

Earlier Oracle Access Manager releases included separate platform-specific installation packages for plain versus SSL-capable modes. For example, two Webgate files were provided for each platform: the APACHE_Webgate, and the APACHESSL_Webgate.

There have been no functional changes to Oracle Access Manager components to support these Web servers. Oracle Access Manager authentication occurs through the Webgate using HTTP basic, form, or SSL client certificates. Authorization for Web resources by authenticated users, and simple and multi-domain SSO with other Web servers or applications, also occurs through the Webgate.

About the Apache HTTP Server

The Apache HTTP Server is an open-source HTTP Web server project of the Apache Software Foundation. The project goal is to provide a secure, efficient and extensible server and HTTP services that meet current HTTP standards.

For more information, see "About Apache v2 Architecture and Oracle Access Manager".

About the IBM HTTP Server

The IBM HTTP Server (IHS) is a variation of Apache v2. Portions of the IBM HTTP Server are based on software developed by The Apache Group. The IBM HTTP Server component also includes software developed by the OpenSSL Project and software developed by Eric Young.

Details about the Apache architecture and Oracle Access Manager, discussed in "About Apache v2 Architecture and Oracle Access Manager" apply to IHS with the following exceptions:

  • Previous versions of IHS required a separate IDS Client to use the mod_ibm_ldap module. With IHS powered by Apache v2.0.47, this is not a requirement.

  • IHS v2.0.47 supports FIPS 140-2. FIPS support is disabled by default. To enable FIPS support, just add the SSLFIPSEnable directive to the httpd.conf file. Similarly, use SSLFIPSDisable directive to disable FIPS support.

  • On AIX, ensure that the appropriate runtime library is installed before you install IHS v2.0.47.

For example on AIX 5.1, the xlC.rte 6.0 runtime library (for example: xlC.rte.6.0.0.0) must be installed before you install IHS v2.0.47. This library is required on AIX to install and use SSL with IHS v2. You can download this library from the following Web site:

http://www-912.ibm.com/eserver/support/fixes/fcgui.jsp

About the Apache and IBM HTTP Reverse Proxy Server

Typically, a reverse proxy is used in the following situations:

  • To provide Internet users with access to a server behind a firewall

  • To balance the load among several back-end servers, or to provide caching for a slower back-end server

  • To bring several servers into the same URL space

The proxy_module implements a proxy/gateway for Apache and IHS powered by Apache. The client requires no special configuration; a reverse proxy appears like an ordinary Web server. The client makes requests as usual for content in the name-space of the reverse proxy. It is the reverse proxy that decides where those requests are sent. Content is returned as if the reverse proxy was the origin.

Important:

The proxy_module can be used to implement a proxy capability for FTP, CONNECT (for SSL), HTTP/0.9, HTTP/1.0, and HTTP/1.1. However, only the reverse proxy capability is supported with the Webgate.

For more information, see "Requirements for Apache v2 Web Servers".

About Apache v2 Architecture and Oracle Access Manager

The Apache v2 Web server provides a hybrid multi-threaded, multi-process architecture that is compatible with the thread-safe Oracle Access Manager libraries.

Important:

Unless explicitly stated otherwise, all details in this discussion apply equally to Apache v2 and IHS v2 Web Servers for 10g Webgates.

In addition to the standard set of modules, the Apache v2 Web server includes Multi-Process Modules (MPMs) to bind network ports on the computer and to accept and process requests. The appropriate MPM must be compiled into the server and activated before you install a Oracle Access Manager component for Apache or IHS v2:

The Apache v2 Web server includes an Apache Portable Runtime (APR) library that provides an interface to platform-specific implementations, assures API developers predictable if not identical behavior regardless of platform, and eliminates the need for conditional compilation #lfdefs. Although backward compatibility is supported with the include/apu_compat.h file, using the Apache v2 APR is recommended.

For more information, see your Apache v2 documentation. See also, "Tuning Apache/IHS v2 for Oracle Access Manager Webgates".

The Apache architecture affects Oracle Access Manager components in different ways, as discussed in the following sections.

For Webgates installed with IHS and Apache v2

Limitations of Apache and IHS v2 Web Servers

Due to limitations of the Apache v2 Web server, plug-ins configured for the Oracle Access Manager form-based authentication scheme do not pass variables when:

For example:

<html>
<form name="myloginform" action="/access/...cgi" method="post">

Requirements for Oracle HTTP Server, IHS, Apache v2 Web Servers

Oracle Access Manager HTML pages use UTF-8 encoding. Apache-based Web servers, including Apache, Oracle HTTP Server, and IBM HTTP Server (IHS) allow administrators to specify a default character set for all HTML pages sent out using the AddDefaultCharset directive. This directive overrides any character specified by the application generating the HTML pages. If the AddDefaultCharset directive enables a character set other than UTF-8, Oracle Access Manager HTML pages are garbled.

Oracle recommends that you specify the AddDefaultCharset directive in the Web server configuration file (httpd.conf) as follows to ensure the correct display of Oracle Access Manager HTML pages:

AddDefaultCharset Off

See your Web server documentation for more information about this directive.

The following topics provide additional details you should be aware of:

Requirements for IHS2 Web Servers

This discussion identifies specific requirements for IHS v2 with Oracle Access Manager. With IHS v2, you do not compile any source code to get the binaries. However, the following requirements do apply to IHS v2 Web servers:

Requirements for Apache and IHS v2 Reverse Proxy Servers

As discussed earlier, the proxy_module implements a proxy/gateway. The client requires no special configuration. Although the proxy_module can be used to implement a proxy capability for FTP, CONNECT (for SSL), HTTP/0.9, HTTP/1.0, and HTTP/1.1, only the reverse proxy capability is supported with certain Oracle Access Manager Apache and IHS v2 Webgates.

For Apache Web Servers: To use reverse proxy functions with Oracle Access Manager, you need to include the proxy module in the configure command. For example:

--enable-proxy: Apache proxy module --enable-proxy-connect: Apache proxy CONNECT module

--enable-proxy-ftp: Apache proxy FTP module

--enable-proxy-http: Apache proxy HTTP module

You also need to load mod_proxy and the mod_proxy_http module into the server dynamically. A reverse proxy is activated using the ProxyPass directive or the [P] flag to the RewriteRule directive.

For IHS Web Servers: After installing the IHS Web server, reverse proxy configurations must be completed in the httpd.conf file in the following directory:

IHS_install_dir/conf directory

For more information, see "Activating Reverse Proxy for Apache v2 and IHS v2".

Requirements for Apache v2 Web Servers

This discussion identifies specific requirements for Apache v2 with Oracle Access Manager. Additional information can be found in your Apache documentation:

PATH Variable: On UNIX systems, your PATH variable must contain the gcc location before you compile Apache v2. However, the Sun C compiler location must not be in your PATH variable. On Windows systems, Apache can be built using either command-line tools or the Visual Studio IDE Workbench. The command-line build requires that the environment reflect the PATH, INCLUDE, LIB and other variables that can be configured with the vcvars32 batch file.

Multi-Process Module (MPM): With Apache v2, a default MPM is provided for each platform to bind network ports on the computer and to accept and process requests. Apache must have one, and only one, MPM in use at any time. If no MPM is selected during compilation, the default will be loaded into the Web server. You may activate the MPM during compilation.

mod_ssl: Oracle Access Manager supports Apache with or without SSL-capable communication. The base Apache Web server does not use SSL for browser connections and will not respond to HTTPS requests. For SSL-capable communication, Oracle Access Manager supports Apache with mod_ssl only. No SSL-specific Oracle Access Manager features operate with Apache-SSL.

mod_ssl relies on OpenSSL to provide the cryptography engine; mod_ssl provides an interface to the OpenSSL library. The OpenSSL library provides Strong Encryption using the Secure Sockets Layer and Transport Layer Security protocols.

With previous versions of Apache, the mod_ssl module had to be downloaded separately and compiled into the server. With Apache HTTP Server v2 module, mod_ssl comes as a loadable module that you can enable during configuration.

Multi-threading: Multi-threading is required for installations with Apache v1.3.27 or later.

Dynamic Shared Object (DSO): DSO support is required for Webgate. Apache modules that extend basic core server functionality may be either statically compiled for permanent inclusion in the Apache binary, or dynamically compiled and stored separately to load at runtime without recompiling. With Apache v1.3, mod_so had to be compiled. With Apache v2 on Windows systems, mod_so is a Base module and always included. With Apache v2 on UNIX, the loaded code typically comes from shared object files.

Note:

Dynamically loaded Apache 1.3 modules cannot be used directly with Apache v2. Apache v1.3 modules must be modified to load dynamically or compile into Apache v2.

mod_perl: mod_perl embeds the Perl programming language in the Apache Web server. Without Perl, Apache v2 can still be built and installed; however, some support scripts written in Perl cannot be used.

Note:

With Apache v.1.3.2x, some operating systems required additional options during configuration. However, to build Apache v2, there is no need to set any additional variables.

Preparing Your Web Server

The methods and steps to prepare your host computer for the Oracle Access Manager Web component installation depends upon the specific Web server and platform, as discussed in the following task overview.

To use reverse proxy functions with Oracle Access Manager, you need to include the proxy module in the configure command, as discussed in "About the Apache and IBM HTTP Reverse Proxy Server". See also "Activating Reverse Proxy for Apache v2 and IHS v2".

Task overview: Preparing your Web server and installing Oracle Access Manager

  1. Install the IHS v2 Web server or compile and install the Apache v2 Web server as discussed in:

  2. Activate reverse proxy capability if desired, as described in "Activating Reverse Proxy for Apache v2 and IHS v2".

  3. Install Oracle Access Manager components, as described elsewhere in this guide.

  4. Finish Web server configuration, as described in "Verifying httpd.conf Updates for Oracle Access Manager Webgates".

  5. Refer to the following topics as needed:

Note:

In all the procedures that follow, path name variables, modules, and options are examples provided only to illustrate the steps. Your environment will vary. Refer to your Web server documentation for additional details.

Preparing the IHS v2 Web Server

To prepare your IHS v2 Web server to accept and use the Webgate for IHS v2, you need to complete one or more of the following procedures, depending on your environment and requirements:

When you have completed the appropriate procedures, you are ready to install the Webgate for IHS v2.

Preparing the Host for IHS v2 Installation

You need to complete this procedure to set up the host computer before you install the IHS Web server. For additional information, see "Requirements for IHS2 Web Servers" and "Requirements for Apache v2 Web Servers".

This example illustrates installation on AIX 5.1. Your environment may vary.

To prepare for IHS v2 installation

  1. On the host computer, download and install the IBM Developer Kit, Java Technology Edition version 1.4 from the following site:

    http://www.ibm.com/java/jdk
    

    The IBM Developer Kit ships with the WebSphere Application Server or can be downloaded from this site.

  2. On the host computer, download and install the xlC.rte 6.0 runtime for AIX 5.1, which is required by the GSKit7 runtime executable from the following site:

    https://techsupport.services.ibm.com/server/aix.fdc
    
  3. On the host computer, create a new directory in which you will uncompress the IBM HTTP Server install image.

  4. On the host computer, download the IBM HTTP Server install image from the following Web site:

    http://www-306.ibm.com/software/webservers/httpservers/

  5. On the host computer, uncompress the install image in your new directory.

    For example:

    tar -xf IHS.tar
    

    A listing of the following files appears, based on your operating system:

    gskit.sh 
    setup.jar  
    gskta.rte (a GSKit runtime executable for AIX)
    

    You are ready to begin the installation, as described next.

  6. Proceed to "Installing the IBM HTTP Server v2".

Installing the IBM HTTP Server v2

The procedure that follows walks you through a typical IBM HTTP Web server installation. Alternatively, you may choose to perform a silent installation. In this case, you use silent.res file with the java -jar setup.jar -silent -options silent.res command. You can customize silent install options by editing the silent.res text file. All options are set to true by default. To disable an option, set its value to false.

To install the IBM HTTP Web server powered by Apache v2

  1. Set your path to point to the Java Technology Edition version 1.4 installed on your computer in the previous example. For example:

    export PATH=$PATH:/usr/java14/java/bin
    
  2. From to the directory where you uncompress the install image, type the following command:

    java -jar setup.jar
    
  3. Choose the language in which to run the installation.

    The Welcome to the InstallShield Wizard for the IBM HTTP Server appears.

  4. Click Next to dismiss the Welcome screen.

  5. Specify the directory name. For example:

    AIX: /usr/IBMIHS/
    
  6. Click Next to continue.

    Options appear for a typical, custom, or developer installation. When you choose a typical installation, a list will appear with everything included and the size of the image. If you choose a custom installation, a list of components appears and you can clear the box next to the any components you do not want to install.

  7. Select the type of installation you would like to perform, then click Next. For example:

    Typical
    

    The following message appears. You can click Cancel to stop the installation.

    Installing IBM HTTP Server. Please wait.
    

    The next message also appears. You can click Cancel to stop the inventory update.

    Updating the inventory.
    
  8. Click Finish to complete your installation.

  9. Stop then start the IHS server using the apachectl commands, as follows:

    For example:

    IHS2_install_dir/bin
       ./apachectl stop
       ./apachectl start
    

    where IHS2_install_dir is the directory where you installed the IHS v2 Web server.

You may configure the IHS v2 Web server in several modes either before or after installing the Webgate for IHS v2:

Setting Up SSL-Capability

If you need to setup SSL-capability, use the following procedure either before or after installing the Webgate for IHS v2.

To setup SSL for IHS v2 using the default configuration file

  1. Locate and open the following file:

    IHS2_install_dir/conf/httpd.conf

  2. Specify the SSLEnable directive to enable SSL.

  3. Specify a Keyfile directive and any SSL directives you want to enable.

  4. Stop then start the IHS server, as follows. For example:

       IHS2_install_dir/bin
       ./apachectl stop
       ./apachectl start
    

    where IHS2_install_dir is the directory where you installed the IHS v2 Web server.

  5. Continue with the following procedures:

Starting a Secure Virtual Host

If you need to start a secure virtual host, use the following procedure either before or after installing the Webgate for IHS v2.

To start an IHS v2 secure virtual host

  1. Locate and open the following file:

    IHS2_install_dir/conf/httpd.conf
    

    where IHS2_install_dir is the directory where you installed the IHS v2 Web server.

  2. Specify the SSLEnable directive in the virtual host stanza of the configuration file, to enable SSL for a virtual host.

    You can specify any directive, with the exception of the cache directives, inside a virtual host.

  3. Specify a Keyfile directive and any SSL directives you want to enable for that particular virtual host.

  4. Load the mod_ibm_ssl.so using the LoadModule directive in the conf file.

  5. Stop then start the IHS virtual host, as follows. For example:

    IHS2_install_dir/bin
       ./apachectl stop
       ./apachectl start
    

    Note:

    The start and stop instructions for an SSL implementation are the same as non-SSL-capable implementations.
  6. Continue with Activating Reverse Proxy for Apache v2 and IHS v2.

Preparing Apache and Oracle HTTP Server Web Servers on Linux

When installing Oracle Access Manager Webgates for Apache or Oracle HTTP Server on Linux, you are prompted to install as the same user under which the Web server is running. See the User and Group directive entries in the httpd.conf file.

When installing Oracle Access Manager Webgates for vendor-bundled Apache v2 on Red Hat Enterprise Linux 4, ensure that all Oracle Access Manager Webgates are installed for Web server user & group (default: apache). See also "Tuning Apache/IHS v2 for Oracle Access Manager Webgates".

Note:

On Linux, Oracle Access Manager Webgates for Oracle HTTP Server 11g use only NPTL; you cannot use the LinuxThreads library. In this case, do not set the environment variable LD_ASSUME_KERNEL to 2.4.19.

Preparing Oracle HTTP Server Web Servers on Linux and Windows Platforms

When using Oracle Access Manager Webgates for Oracle HTTP Server v2 on Windows and Linux platforms, both the Perl module and the PHP module must be commented out in the httpd.conf.

Note:

With Oracle HTTP Server 11g, there is no need to comment out any module for Oracle Access Manager Webgates on any platform.

Setting Oracle HTTP Server Client Certificates

When using cert_decode and credential_mapping authentication modules, you must ensure that the Client Certificate authentication scheme works properly with SSL-enabled Oracle HTTP Server by adding +EarlierEnvVars and +ExportCertData to the existing SSL options in the Oracle HTTP Server Web server configuration file. For example:

credential_mapping:

obMappingBase="o=company,c=us",obMappingFilter=
     "(&(objectclass=InetOrgPerson)(mail=%certSubject.E%))"

ssl.conf must include:

SSLOptions +StdEnvVars +ExportCertData +EarlierEnvVars

To add ssl options to Oracle HTTP Server

  1. Locate and open the Oracle HTTP Server Web server configuration file with a text editor. For example:

    $ORACLE_INSTANCE/ohs/conf/ssl.conf

  2. In the ssl.conf file, add the following information to existing SSL options. For example:

    SSLOptions +StdEnvVars +ExportCertData +EarlierEnvVars
    
  3. Save the file and restart the Web server.

Preparing the Apache v2 Web Server on UNIX

This discussion provides an overview and steps to prepare the Apache v2 HTTP Web server for Oracle Access Manager on UNIX platforms, including Solaris, UNIX, Linux, and AIX. See also "Preparing the Apache v2 SSL Web Server on AIX"

Apache v2 can be configured, built, and installed plain or as SSL-capable. After downloading and extracting Apache source files, you use a script (configure script on UNIX and the makefile.win make script for Windows) to compile the source tree for your environment.

Note:

Basic requirements are the same regardless of your platform. However, the remainder of this discussion and the procedures that follow focus on UNIX platforms. For more information, see also "Preparing the Apache v2 SSL Web Server on AIX".

When you configure Apache v2 on UNIX platforms, you specify the installation directory path name using the -prefix= option with the ./configure command. During configuration you enable the modules that are appropriate for your environment. For example, mod_so is included in the server automatically when dynamic modules are included in the compilation. However, you can ensure the server is capable of loading DSOs by including the -enable-so option with the configure command. If you have multiple Perl interpreters installed, you can include the -with-perl option to ensure the correct interpreter is selected during configuration.

In the configure command, you can also include the options to enable mod_ssl, and to activate an MPM. After configuration, you can verify which MPM was chosen using ./httpd -l to list every module that is compiled into the server.

When you finish configuring Apache, you build the various parts that form the Apache package using the make command then install the package under the installation directory you specified with the -prefix= option during configuration.

For steps and examples, see the following procedures and your Apache documentation:

In the procedures that follow, path name variables, modules, and options are examples provided only to illustrate the steps. Your environment will vary. Refer to your Web server documentation for additional details. There is no difference in the build procedure between Apache v2.0.48 and v2.0.52.

To prepare plain Apache v2 for UNIX

  1. Confirm that your environment meets Apache requirements for the appropriate compiler and build tools, as described in Apache documentation located at:

    http://httpd.apache.org/docs-2.0/install.html#requirements
    

    Note:

    There are no known restrictions with regard to supported compiler versions for Apache v2 and Oracle Access Manager plug-ins. See the Apache documentation.
  2. Download a complete, unmodified version of the Apache HTTP Server v2, as described in the Apache documentation. For example:

    http://httpd.apache.org/download.cgi
    

    Note:

    Be sure to download Perl, if needed.
  3. Extract (uncompress, then untar) source files from the tarball, as described in the Apache documentation. For example:

    gzip -d httpd-2_0_48.tar.gz
       tar -xvf httpd-2_0_48.tar
    

    You can use the following step as an example of configuring the Apache source tree. If you compile Apache on UNIX with the mpm_worker_module for Webgate, see "Apache v2 on UNIX with the mpm_worker_module for Webgate".

    Note:

    To use reverse proxy functions with Oracle Access Manager, you need to include the proxy module in the configure command, as discussed in "About the Apache and IBM HTTP Reverse Proxy Server".
  4. Ensure that you have the correct version of GNU gcc libraries in the proper path to build the Apache source; gcc libraries should be in the PATH:

    export PATH=/usr/local/packages/gcc-3.4.6/bin:$PATH
    
  5. Configure the Apache source tree and enable or activate the desired modules using details in the Apache documentation. For example:

    cd apache_source_dir
    ./configure --with-mpm=prefork --prefix=apache_install_dir --with-included-apr
    ./configure --with-mpm=worker --prefix=apache_install_dir --with-included-apr
    

    where apache_source_dir refers to the directory where you extracted Apache and apache_install_dir refers to the directory where you want to install Apache.

  6. Compile the Apache package you configured using the make command. For example:

    make
    
  7. Install the Apache package in the configured directory path that you specified earlier using the --prefix= option. For example:

    make install
    
  8. Customize the installation using instructions in the Apache documentation.

    For example, you may need to tune the httpd.conf to set basic values for:

    ServerName
       User/owner of the WebServer
       Group
    

    Note:

    To view the complete list of values, use the command: ./configure --help.
  9. Stop then restart the Apache Web server to test the installation using commands in the apache_install_dir/bin directory. For example:

    ./apachect1 stop
       ./apachectl start
    
  10. Continue with appropriate tasks for your environment, as follows:

The following procedure outlines how to prepare an SSL-capable Apache v2 Web server on UNIX. The Apache mod_ssl is loadable; however, this installation requires the Open Source toolkit for SSL/TLS. Again, be sure to download Perl, if needed. If AIX is the platform you are using, be sure to see "Preparing the Apache v2 SSL Web Server on AIX" for additional information.

To prepare SSL-capable Apache v2 on UNIX

  1. Confirm that your environment meets Apache requirements for the appropriate compiler and build tools, as described in Apache documentation located at:

    http://httpd.apache.org/docs-2.0/install.html
    
  2. Download a complete, unmodified version of the Apache HTTP Server v2 and Open Source, as described in the Apache documentation.

    http://httpd.apache.org/download.cgi
    http://www.openssl.org/
    
  3. Extract (uncompress, then untar) source files from the tarballs, as described in the Apache documentation. For example:

    gzip -d httpd-2_0_48.tar.gz
       tar -xvf httpd-2_0_48.tar
       gzip -d openssl-0_9_6f.tar.gz
       tar -xvf openssl-0_9_6f.tar
    
  4. Configure the OpenSSL source tree, as described in Apache documentation. For example:

    cd openssl_source_dir
       ./config -fPIC --prefix=openssl_install_dir 
    

    where openssl_source_dir refers to the directory where you extracted OpenSSL and openssl_install_dir refers to the directory where you want to install the configured OpenSSL package.

  5. Compile the OpenSSL package in the installation directory you configured using the make command with the --prefix= option. For example:

    make
    
  6. Issue the make test command to complete any sanity testing of OpenSSL and check the correct version of the tools required. For example:

    make test
    
  7. Install the OpenSSL package in the configured directory path that you specified earlier using the --prefix= option. For example:

    make install
    
  8. Configure the Apache source tree and enable or activate desired modules, as described in your Apache documentation. For example:

    cd apache_source_dir ./configure --prefix=apache_install_dir
     --enable-so \ --with-mpm='prefork' --with-perl=perl_interpreter_path \ 
    --with-port=non_ssl_port --enable-ssl \ --with-ssl=openssl_install_dir
    

    where apache_source_dir refers to the directory where you extracted Apache; apache_install_dir refers to the directory where you want to install Apache; and openssl_install_dir refers to the directory where you installed the configured OpenSSL package.

  9. Compile using the make command to build the Apache SSL-capable package in the installation directory you configured using the --prefix= option. For example:

    make install
    
  10. Install the Apache SSL-capable package in the configured directory path that you specified earlier using the --prefix= option. For example:

    make install
    

    You must explicitly make certificates for the Apache v2 server to enable SSL using the openssl tool located at openssl_install_dir/bin/. The make certificate command does not work with Apache v2.

  11. Make certificates using the OpenSSL tool in the openssl_install_dir/bin directory, as described in your OpenSSL documentation and remember that "Common Name" is the fully qualified host name.

  12. Customize the installation using instructions in the Apache documentation:

    • Tune the httpd.conf to set basic values for:

      ServerName
      User/owner of the WebServer
      `Group
      
    • Tune the ssl.conf to set basic values for:

      Listen 7000
       <VirtualHost _default_:7000>
       ServerName ps0733.persistent.co.in:7000
       SSLCertificateFile /home/qa/software/ws/apache/
       apache-2.0.48_ssl_7000/conf/ssl.crt/server.crt
       SSLCertificateKeyFile /home/qa/software/ws/apache/
       apache-2.0.48_ssl_7000/conf/ssl.key/server.key 
      
  13. Stop then restart the Apache Web server to test the installation using commands in the apache_install_dir/bin directory. For example:

    ./apachectl stop   
       ./apachectl startssl
    
  14. Continue with Activating Reverse Proxy for Apache v2 and IHS v2, if needed.

Preparing the Apache v2 SSL Web Server on AIX

While building the Apache v2 SSL Web server, the symbols from the OpenSSL Library libssl.a are exported into the httpd executable in Apache. The symbols needed by Oracle Access Manager from the OpenSSL library are:

  • SSL_get_peer_certificate( )

  • i2d_X509( )

During linking and binding on the AIX platform, any unused or unreferenced symbols are deleted. Therefore, the two symbols required by Oracle Access Manager are missing from the httpd executable.

You need to use openssl-0.9.7d to compile on AIX (openssl-0.9.7e does not compile on AIX). The rest of the steps are the same as on UNIXopenssl-0.9.7d.

Client Cert Authentication: If you are using Client Cert Authentication on the AIX platform, be sure to use AIX 5.2 Maintenance Level 4 with the following hot fix applied for dlsym problem on AIX:

http://www-1.ibm.com/support/docview.wss?uid=isg1IY63366

To prepare the AIX platform for Apache v2

  1. Ensure that your AIX platform meets the system requirements for Oracle Access Manager.

  2. See details in "Preparing the Apache v2 Web Server on UNIX" and when building the Apache v2 Web server:

    • Use openssl-0.9.7d to compile the Web server for AIX.

    • Use the make command in the following manner:

      make MFLAGS=EXTRA_LDFLAGS='-Wl,-bE:OpenSSL_Symbols.exp'
      

where OpenSSL_Symbols.exp is the file containing the two required symbols. The symbol must be exported using the export file only, as shown.

Note:

Do not export the symbol on AIX with the following methods: -bnog: To suppress garbage collection of symbols -bexpal: To export all symbols -uSymbolName: To export a particular symbol.

Preparing the Apache v2 Web Server on Windows

Following are some details about how installing and configuring Apache v2 on Windows differs from Apache v2 on UNIX. For more information, see your Apache documentation.

During Installation: Apache will configure files in the \conf subdirectory to reflect the chosen installation directory. If any configuration files in this directory already exist, a new copy of the corresponding file will be written with the extension .ORIG. For example, \conf\httpd.conf.ORIG.

After Installation: Apache is configured using the files in the \conf subdirectory. These are the same files used to configure the UNIX version. However, there are a few differences.

You must edit the configuration files in the \conf subdirectory to customize Apache for your environment. These files will be configured during the installation; Apache is ready to run from the installation directory, with the documents server from the subdirectory htdocs. There are many options you should set before starting to use Apache. For example, Apache listens on port 80 unless you change the Listen directive in the configuration files or install Apache only for the current user.

Multi-Threading: Apache for Windows is multi-threaded, which means that it does not use a separate process for each request as Apache does on UNIX. Instead there are usually only two Apache processes running: a parent process, and a child which handles the requests. Within the child process each request is handled by a separate thread.

UNIX-Style Names: Apache uses UNIX-style names internally. The directives that accept filenames as arguments must use Windows filenames instead of UNIX filenames. However, you must use forward slashes, not back slashes. Drive letters may be used. However, if a drive letter is omitted, the drive with the Apache executable is assumed.

LoadModule Directive: Apache for Windows includes the ability to load modules at runtime without recompiling the server. If Apache is compiled normally, it will install a number of optional modules in the \Apache2\modules directory. To activate these or other modules, you must use the LoadModule directive. For example, to activate the status module, use the following (in addition to the status-activating directives in access.conf):

LoadModule status_module modules/mod_status.so

On UNIX, the loaded code typically comes from shared object files (.so extension), on Windows this may be either the .so or .dll extension.

Process Management Directives: These directives are also different for Apache on Windows.

Error Logging: During Apache startup, any errors are logged into the Windows event log, which provides a backup to the error.log file. For more information, see your Apache documentation.

Apache Service Monitor: Apache comes with an Apache Service Monitor utility. With it you can see and manage the state of all installed Apache services on any computer on your network. To manage an Apache service with the monitor, you must first install the service. Apache may be run as a service on Windows. For details, see your Apache documentation.

Starting, Restarting, Shutting Down: Running Apache as a service is the recommended method. An Apache service is typically started, restarted, and shut down using the Apache Service Monitor and commands like NET START Apache2 and NET STOP Apache2. You may also use standard Windows service management.

You may work with Apache from the command line using the apache command. Apache will execute and remain running until it is stopped by pressing Control-C. You may also run Apache from the Start Menu during installation.

Note:

Pressing Control-C may not allow Apache to end any current operations and clean up gracefully.

Apache Services Accounts: By default, all Apache services are registered to run as the system user (the LocalSystem account). The LocalSystem account has no network privileges through any Windows-secured mechanism. However, the LocalSystem account has wide privileges locally. For details about creating a separate account to run one or more Apache services, see your Apache documentation.

To prepare Apache v2 for Windows

  1. Confirm that your environment meets Apache requirements, as described in Apache documentation located at:

    http://httpd.apache.org/docs-2.0/install.html
    

    For Windows installations a list of HTTP and FTP mirrors from which you can download Apache v2 is provided online.

    When you complete the next step, be sure to download the version of Apache for Windows with the .msi extension.

  2. Download a complete, unmodified version of the Apache HTTP Server v2 (and OpenSSL), as described in the Apache documentation. For example:

    http://httpd.apache.org/download.cgi
    http://www.openssl.org/
    
  3. Install Apache v2 (run the .msi file you downloaded and supply requested information), using your Apache documentation as a guide.

  4. Locate the .default.conf file, verify new settings, then update your existing configuration file if needed.

  5. Start Apache, either in a console window or as a service.

  6. Launch a browser and enter the following URL to connect to the server and access the default page. For example:

    http://localhost/
    

    A welcome page and a link to the Apache manual should appear. If not, look in the error.log file in the logs subdirectory.

    Once your basic installation is working, you need to configure it properly by editing the files in the \conf subdirectory.

  7. Configure the Apache installation for your environment, using the Apache documentation as a guide.

  8. Test your customized environment.

  9. Continue with Activating Reverse Proxy for Apache v2 and IHS v2, if needed.

Activating Reverse Proxy for Apache v2 and IHS v2

The Webgates for Apache v2 and IHS v2 powered by Apache support reverse proxy capability, if you choose to activate this capability. The procedures to implement reverse proxy capability differ, depending on your environment:

Activating Reverse Proxy For Apache v2 Web Servers

For reverse proxy functions with Oracle Access Manager, you need to include the Apache proxy module in the configure command for the Web server. You also need to load mod_proxy and the mod_proxy_http module into the server dynamically. A reverse proxy is activated using the ProxyPass directive or the [P] flag to the RewriteRule directive.

Reverse proxy capability is activated using the ProxyPass directive or the [P] flag to the RewriteRule directive. It is not necessary to turn ProxyRequests on to configure a reverse proxy. Access control is less critical when using a reverse proxy (ProxyPass directive with ProxyRequests Off), because clients can contact only the hosts that you have specifically configured. You can control access to your proxy using the <Proxy> control block.

To activate reverse proxy capability for Apache v2 Web servers

  1. Review "About the Apache and IBM HTTP Reverse Proxy Server".

  2. Include the Apache proxy module in the configure command for the Web server, if needed.

    For example:

    --enable-proxy      
    --enable-proxy-connect      
    --enable-proxy-ftp      
    --enable-proxy-http
    

    See the Apache documentation for more information.

  3. Use the ProxyPass directive or the [P] flag to the RewriteRule directive to activate a reverse proxy, as follows:

    Reverse Proxy
            ProxyRequests Off
            <Proxy *>
             Order deny,allow
             Allow from all
            </Proxy>
            ProxyPass /foo http://foo.example.com/bar
            ProxyPassReverse /foo http://foo.example.com/bar 
    
  4. Control access to your proxy using the <Proxy> control block as follows:

    <Proxy *>
           Order Deny,Allow
           Deny from all
           Allow from 192.168.0
          </Proxy> 
    
  5. Perform steps in Chapter 27, "Managing OAM 10g Webgates with OAM 11g", if you haven't yet done so.

Activating Reverse Proxy For IHS v2 Web Servers

Use the following procedure after installing the Web server.

To activate reverse proxy capability for IHS v2 Web servers

  1. Review "About the Apache and IBM HTTP Reverse Proxy Server"

  2. Install the IHS v2 Web server, as described in "Preparing the IHS v2 Web Server".

  3. Load the modules by including these lines (uncommented) in the Dynamic Shared Object section of the httpd.conf file in:

    IHS_install_dir/conf/httpd.conf

    LoadModule access_module modules/mod_access.so
          LoadModule auth_module modules/mod_auth.so
          LoadModule auth_dbm_module modules/mod_auth_dbm.so
          LoadModule include_module modules/mod_include.so
          LoadModule log_config_module modules/mod_log_config.so
          LoadModule env_module modules/mod_env.so
          LoadModule unique_id_module modules/mod_unique_id.so
          LoadModule setenvif_module modules/mod_setenvif.so
          LoadModule proxy_module modules/mod_proxy.so
          LoadModule proxy_connect_module modules/mod_proxy_connect.so
          LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
          LoadModule proxy_http_module modules/mod_proxy_http.so
          LoadModule mime_module modules/mod_mime.so
          LoadModule dav_module modules/mod_dav.so
          LoadModule autoindex_module modules/mod_autoindex.so
          LoadModule asis_module modules/mod_asis.so
          LoadModule info_module modules/mod_info.so
          LoadModule cgid_module modules/mod_cgid.so
          LoadModule dav_fs_module modules/mod_dav_fs.so
          LoadModule vhost_alias_module modules/mod_vhost_alias.so
          LoadModule dir_module modules/mod_dir.so
          LoadModule imap_module modules/mod_imap.so
          LoadModule actions_module modules/mod_actions.so
          LoadModule userdir_module modules/mod_userdir.so
          LoadModule alias_module modules/mod_alias.so
          LoadModule rewrite_module modules/mod_rewrite.so
    
  4. Directives Under the IfModule mod_proxy.c Tag--Use the information and the following examples to ensure that:

    • Allow or Deny conditions are appropriately commented.

      For example:

      <Proxy *>
            Order deny, allow
      #    Deny from all
            Allow from all
      #   Allow from .domain.com
      </Proxy>
      
    • URLs to be protected are mentioned in both the ProxyPass and the ProxyPassReverse directives.

      For example:

      <IfModule mod_proxy.c>
      ProxyRequests Off
      ProxyPass /testproxy http://bedford: 8809/testrev/
      ProxyPassReverse /testproxy http://bedford: 8809/testrev/
      ProxyPass /test2 http://bedford: 8809/testrev/
      ProxyPassReverse /test2 http://bedford: 8809/testrev/
      
  5. Restart the Web server after any modifications to the httpd.conf file.

  6. Testing: To access the proxy URL, access http://<proxy_host>:80/testproxy/

    Note:

    While testing, make sure the URLs have a trailing forward slash. Sometimes resources cannot be accessed without the forward slash at the end.

  7. Enabling SSL on Reverse Proxy Server: Use the documentation on the IHS default page.

    For example, sample SSL settings in the DSO section of the httpd.conf file load the ibm_ssl_module as:

    LoadModule ibm_ssl_module modules/mod_ibm_ssl.so
    
  8. Include the following directives in your httpd.conf file:

    SSLEnable
          Keyfile /opt/IBMIHS/bin/key.kdb
          SSLClientAuth none
          SSLProxyEngine on
    
  9. Restart server.

  10. Access the Web server URL and confirm that the browser is presented with a certificate.

    Note:

    You can switch back to open mode for the Web server simply by commenting out the preceding directives and restarting the server.
  11. key.kdb: To generate the key.kdb, use the ikeyman utility (preferably in GUI mode) provided in the IHS_install_dir/bin directory.

    Note:

    The ikeyman utility uses the gsk7bas utility. However, you need to apply fix pack PQ83048 on gsk7bas.
  12. Perform the following steps:

Verifying httpd.conf Updates for Oracle Access Manager Webgates

It is a good idea to complete the following procedures to ensure that the Apache or IHS v2 httpd.conf file includes Web server configuration updates for Oracle Access Manager. For details, see:

To update httpd.conf for reverse proxy on IHS Web servers, see "Activating Reverse Proxy For IHS v2 Web Servers". To customize httpd.conf for your Web server, see your Web server documentation.

Verifying Webgate Details

The example that follows shows the Webgate section in the httpd.conf file. The details will vary, depending on your environment. This example is provided only to illustrate the type of changes you will see in httpd.conf.

To verify the Webgate section in httpd.conf

  1. Locate the updated httpd.conf file on the computer hosting the Webgate.

  2. Open the httpd.conf file and ensure that the section that loads the Webgate in your platform is present.

    For example:

    On Windows

    #*** BEGIN Oblix NetPoint Webgate Specific **** 
    <IfModule mod_ssl.c>
    LoadModule obWebgateModule "WebGate_install_dir\access\oblix\apps\webgate\bin\webgatessl.d ll"
          WebGateInstalldir "WebGate_install_dir"
          WebGateMode PEER
          </IfModule>
    <IfModule !mod_ssl.c>
    LoadModule obWebgateModule "WebGate_install_dir\access\oblix\apps\webgate\bin\webgate.dll"
          WebGateInstalldir "WebGate_install_dir"
          WebGateMode PEER
          </IfModule>
    <Location "\oberr.cgi">
    SetHandler obwebgateerr
          </Location>
          <LocationMatch "/*">
          AuthType Oblix
          require valid-user
          </LocationMatch>
    #*** END Oblix NetPoint Webgate Specific **** 
    

    On UNIX

    #*** BEGIN Oblix NetPoint Webgate Specific **** 
    LoadFile "/home/qa/netpoint/703/c1-copy/wg/access/oblix/lib/libgcc_s.so.1"
    LoadFile "/home/qa/netpoint/703/c1-copy/wg/access/oblix/lib/libstdc++.so.5"
    <IfModule mod_ssl.c>
       LoadModule obWebgateModule "/home/qa/netpoint/703/c1-copy/wg/access/oblix/ apps/webgate/bin/webgatessl.so"
    </IfModule>
    <IfModule !mod_ssl.c>
       LoadModule obWebgateModule "/home/qa/netpoint/703/c1-copy/wg/access/oblix/ apps/webgate/bin/webgate.so"
    </IfModule>
    WebGateInstalldir "/home/qa/netpoint/703/c1-copy/wg/access"
    WebGateMode PEER
    <Location /access/oblix/apps/webgate/bin/webgate.cgi> 
    SetHandler obwebgateerr 
    </Location>
    <Location "/oberr.cgi">
    SetHandler obwebgateerr
    </Location>
    <LocationMatch "/*">
    AuthType Oblix
    require valid-user
    </LocationMatch>
    #*** END Oblix NetPoint Webgate Specific ****
    

Notes for UNIX

When running Apache v2 on HP-UX, do not use nobody for User or Group, because shared memory may not work. Instead, use your login name as User Name with a group Group as "Oblix" (or "www" as User Name and "others" as Group Name). On HP-UX, "www" is equivalent to "nobody" on Solaris.

When running Apache v2 on HPUX 11.11, ensure that the AcceptMutex directive in the Apache httpd.conf file is set to "fcntl". If the directive is not present, add it to the httpd.conf file (AcceptMutex fcntl). For more information, see http://issues.apache.org/bugzilla/show_bug.cgi?id=22484).

Notes for IHS on AIX

#*** BEGIN Oblix NetPoint Webgate Specific ****
   LoadModule obWebgateModule DR/oblix/apps/webgate/bin/webgate.so
   WebGateInstalldir DR
   WebGateMode PEER
   <Location "/oberr.cgi">
      SetHandler obwebgateerr
   </Location>
   <LocationMatch "/*">
      AuthType Oblix
         require valid-user
   </LocationMatch>
#*** END Oblix NetPoint Webgate Specific ****
  1. Use the chmod -r username:groupname directory/file to change the User Name and Group Name of a directory or a file.

    When you do this, you need to change the User and Group parameters in the httpd.conf file accordingly.

  2. See "Tuning Apache/IHS v2 for Oracle Access Manager Webgates" for more information and complete any additional steps needed to finish the Oracle Access Manager implementation for Apache v2.

    Important:

    You use the following procedure only if you need to clear the httpd.conf file of Webgate-related changes, then complete the Apache v2 Web server configuration for the Webgate anew.

To start httpd.conf updates anew

  1. Restore the original httpd.conf file to remove any Oracle Access Manager entries that are present.

  2. Update the httpd.conf file for Oracle Access Manager using one of the following methods:

    • Either open the file component_install_dir/access/oblix/lang/LangTag/docs/config.htm and perform a manual configuration, as described in Chapter 27, "Managing OAM 10g Webgates with OAM 11g".

    • Or launch the ManageHttpConf program in component_install_dir/access/oblix/tools/setup/InstallTools/ManageHttpConf without any options to print instructions on its use.

      Note:

      If the ManageHttpConf program is run with Webgate entries already present in the httpd.conf file, an error message will be printed and the httpd.conf file will not be updated.
  3. Complete activities in "Tuning Apache/IHS v2 for Oracle Access Manager Webgates".

Verifying Language Encoding

As mentioned earlier, Oracle Access Manager HTML pages use UTF-8 encoding. Apache-based Web servers allow administrators to specify a default character set for all HTML pages sent out using the AddDefaultCharset directive, which overrides any character specified by the application generating the HTML pages. If the AddDefaultCharset directive enables a character set other than UTF-8, Oracle Access Manager HTML pages are garbled.

To ensure proper language encoding

  1. Open the httpd.conf file.

  2. Locate the AddDefaultCharset directive.

  3. Complete one of the following activities to ensure that proper encoding of Oracle Access Manager HTML pages:

    • Either set the AddDefaultCharset directive to Off.

    • Or Comment out the AddDefaultCharset directive.

  4. Save the httpd.conf file and restart the Web server.

Tuning Oracle HTTP Server for Oracle Access Manager Webgates

After installing the Oracle Access Manager Web component for Oracle HTTP Server, you need to complete the steps that follow.

As mentioned earlier, before installing Oracle Access Manager Webgates for Oracle HTTP Server, in the httpd.conf file you must change the user and group to match the user that is installing the component.

Note:

On Linux, Oracle Access Manager Webgates for Oracle HTTP Server 11g use only NPTL; you cannot use the LinuxThreads library. In this case, do not set the environment variable LD_ASSUME_KERNEL to 2.4.19.

To tune Oracle HTTP Server for Oracle Access Manager Webgates

  1. Shut down opmn, as you usually do.

  2. Locate and open the opmn.xml file for editing. For example:

    $oracle_home/opmn/bin/opmn.xml

  3. In the opmn.xml file, adjust items as follows:

    <ias-component id="HTTP_Server">
    <process-type id="HTTP_Server" module-id="OHS2">
             <environment>
                    <variable id="TMP" value="/tmp"/>
                    <variable id="LD_ASSUME_KERNEL" value="2.4.19"/>
             </environment>
              <module-data>
                <category id="start-parameters">
                  <data id="start-mode" value="ssl-disabled"/>
                </category>
              </module-data>
              <process-set id="HTTP_Server" numprocs="1"/>
            </process-type>
          </ias-component>
    
  4. Refresh the OPMN configuration by executing the following script:

    #oracle_home/opmn/bin/opmnctl reload
    
  5. Start the Oracle HTTP Server Web server, as described in "Starting and Stopping Oracle HTTP Server Web Servers"

Tuning OHS /Apache Prefork and MPM Modules for OAM

Oracle recommends specific tuning parameters with Oracle Access Manager Webgates for these Web servers.

The tuning parameters described in this section are configured in the httpd.conf file with Apache v2.0 and OHS11g.

For Apache v2.2, however, tuning is configured in the following files:

apache_install_dir/conf/extra/httpd-mpm.conf

apache_install_dir/conf/extra/httpd-default.conf

Also for Apache v2.2, the entries for httpd-mpm.conf and httpd-default.conf should be uncommented, as follows:

From:

#Include conf/extra/httpd-mpm.conf
#Include conf/extra/httpd-default.conf

To:

Include conf/extra/httpd-mpm.conf
Include conf/extra/httpd-default.conf

Use the following topics as needed for your environment:

Tuning Oracle HTTP Server /Apache Prefork Module

Oracle recommends the following as broad guidelines when using Oracle Access Manager with either the Oracle HTTP Server or Apache Prefork module:

Timeout 300

KeepAlive On

MaxKeepAliveRequests 500

KeepAliveTimeout 10

StartServers: 5 (Initial number of processes to start; used only on startup.)

MaxClients: 500 (Total number of processes to handle load at peak time. Determines how many child processes will be created to handle requests at peak period.

ServerLimit: 500 (The maximum configured value for MaxClients for the lifetime of the process. If MaxClients is set to a value higher than the default, ServerLimit value should be specified above the rest of the parameters.

MinSpareServers, MaxSpareServers: Default values should suffice requirements to handle a heavy load. During operation, these values regulate how the parent process creates children to serve requests.

MaxRequestsPerChild: 0 - Number of requests sent to each child process. 0 indicates the process never expires/dies

Tuning Oracle HTTP Server /Apache MPM Module

Oracle recommends the following as broad guidelines when using Oracle Access Manager with either the Oracle HTTP Server or Apache Prefork module:

Timeout 300

KeepAlive On

MaxKeepAliveRequests 500

KeepAliveTimeout 10

StartServers: 2 (Initial number of processes to start; used only on startup.)

MaxClients: 500 (Total number of processes to handle load at peak time. Determines how many child processes will be created to handle requests at peak period.

ServerLimit: 25 (The maximum configured value for MaxClients for the lifetime of the process. If MaxClients is set to a value higher than the default, ServerLimit value should be specified above the rest of the parameters.

MinSpareServers, MaxSpareServers: 25, 75. During operation, these values regulate how the parent process creates children to serve requests.

ThreadsPerChild: 25 (The number of worker threads in single httpd process.)

MaxRequestsPerChild: 0 (This directive sets the limit on the number of requests that an individual child server process will handle. The value 0 will ensure that the process never expires.)

Kernal Parameters Tuning

Oracle Recommends that you ensure that the kernal parameters for the soft and hard limit on the file descriptors are set to a high value. For example:

Hard limit (rlim_fd_max): 65535

Soft limit (rlim_fd_cur): 65535

The high value of the file descriptor is a strong recommendation for the Apache server that will open and close sockets for requests.

Starting and Stopping Oracle HTTP Server Web Servers

Starting and stopping an Oracle HTTP Server Web server is the same procedure for both v1.3 and v2, on all platforms.

To start the Oracle HTTP Server Web server

  1. Locate and change to the following directory:

    $ORACLE_HOME\opmn\bin\

  2. From the command line, enter the following command:

    opmnctl/startproc process-type=HTTP_Server
    

To stop the Oracle HTTP Server Web server

  1. Locate and change to the following directory:

    $ORACLE_HOME\opmn\bin\

  2. From the command line, enter the following command:

    opmnctl/stopproc process-type=HTTP_Server
    

Tuning Apache/IHS v2 for Oracle Access Manager Webgates

Unless explicitly stated, information here applies to both Apache and IHS v2 Webgate components (also known as plug-ins). For details about Oracle HTTP Server, see the Oracle HTTP Server Administrator's Guide 10 g R2 (10.1.2).

Apache v2 bundled with Security-Enhanced Linux: With SELinux, errors could be reported in WebServer logs/console when starting a Web server on Linux distributions that have more strict SELinux policies in place after installing an Oracle Access Manager Web component. You can avoid these errors by running appropriate chcon commands for the installed Web component before restarting the Web server.

See Also:

"SELinux Issues"

Apache v2 bundled SELinux-enabled Linux Distribution: Security-enhanced Linux (SELinux) is an automatically enabled implementation of a mandatory access-control mechanism. As described in your Linux documentation, SELinux policies provide access to certain pre-defined system directories such as /etc/httpd/conf, /usr/sbin/apachect, and /var/log/ (to name a few) for system daemons.

When Oracle Access Manager Webgates are installed with the bundled Apache Web server, certain policies must be added to allow Apache processes to access Oracle Access Manager installation files.

The bundled Apache Web server runs as user "apache" with a security context defined as context=user_u:system_r:unconfined_t. As a result, when Oracle Access Manager Webgates are installed in any of the user folders, the Apache Web server will not start.

The $SELINUX_SRC variable represents the SELinux policy source directory. The default value is /etc/selinux/targeted/src/policy. However, your environment may vary. Be sure to consult your system administrator for the actual value for your system.

To add Oracle Access Manager policies to Apache bundled with Red Hat Enterprise Linux 4

  1. After installing each Oracle Access Manager Web component, log in as the 'root' user.

  2. Ensure that all Oracle Access Manager Webgates are installed for Web server user & group (default: apache).

  3. Create an oracle_access_manager.te policy file in the $SELINUX_SRC/domains/programs/directory and add the following rules:

    type oracle_access_manager_t, file_type, sysadmfile; 
    allow httpd_t oracle_access_manager_t:file { rw_file_perms create rename
    link unlink setattr execute };
    allow httpd_t oracle_access_manager_t:dir  { rw_dir_perms create append
    rename link unlink setattr }; 
    
  4. Create an oracle_access_manager.fc file context in the directory $SELINUX_SRC/file_contexts/program, then register the Oracle Access Manager Web component installation directory (without identity or access suffix). For example:

    Oracle_Access_Manager_install_dir(/.*)? system_u:object_r:oracle_access_
     manager_t
    

    Note:

    When the Webgate is installed in a separate directory from the Access Manager, be sure to register the Webgate installation directory separately.
  5. Compile and deploy the policy files as follows:

    cd $SELINUX_SRC
    make load
    Label Oracle Access Manager files
    run restorecon -R Oracle_Access_Manager_install_dir (without the identity or access suffix)
    

Apache v2 Directives: Apache 1.3 uses a process model for serving multiple HTTP requests at once. This differs from the single process (thread) model employed by other Web servers, which manage several requests simultaneously in one process.

Note:

Only the prefork MPM in Apache v2 uses the same process model for serving HTTP requests as Apache v1.3. For all other MPMs, Apache v2 uses a hybrid process-thread model.

Several directives in the Apache v2 Web server configuration file (httpd.conf) affect how the Apache Web server decides to create or destroy worker processes. The following parameters affect the performance of the Apache v2 Web server:

Appropriate values for the preceding parameters depend on the expected load and the performance class of the systems involved, including the Access Server and LDAP server.

Apache servers on very high performance systems with high expected loads may be recompiled with a larger limit on the number of worker processes. These systems may see a greater performance impact on the StartServers and MinSpareServers parameters for dealing with sudden load spikes.

You may need to adjust operating system limits for the Access Server for proper operation. In particular, the maximum number of file descriptors available for any one Access Server may need to be increased beyond the default value. Configuring more than one connection between each Apache-based Webgate and an Access Server may quickly exceed this limit.

For additional information, see your Apache documentation.

Removing Web Server Configuration Changes After Uninstall

Web server configuration changes that occur during installation must be manually removed after uninstalling the Webgate). This type of information must be removed manually.

Further, you must remove any changes that you manually made to your Web server configuration file for the Webgate) should be removed. For more information about what is added for each component, look elsewhere in this chapter.

Helpful Information

Consult the following manual for more information about the Oracle HTTP Server:

Oracle HTTP Server Administrator's Guide 10 g R2 (10.1.2)

The following URLs provide information about building an Apache release and source code:

Apache v2 documentation:

http://httpd.apache.org/docs-2.0/

Apache v2 source code:

http://httpd.apache.org/download.cgi

Mod-SSL documentation:

http://httpd.apache.org/docs-2.0/mod/mod_ssl.html

OpenSSL documentation:

http://www.openssl.org/docs/

OpenSSL source code:

http://www.openssl.org/source/

Compiling and Installing Apache v2:

http://httpd.apache.org/docs-2.0/install.html#test

IHS:

http://www-306.ibm.com/software/webservers/httpservers/doc/v2047/manual/readme.html