Skip Headers

Oracle® HTTP Server Administrator's Guide
10g (9.0.4)
Part No. B10381-02
  Go To Documentation Library
Home		 Go To Product List
Solution Area		 Go To Table Of Contents
Contents		 Go To Index
Index
Previous Next  

10 Managing Security

This chapter contains an overview of Oracle HTTP Server security features, and provides configuration information for setting up a secure Web site.

Topics discussed are:

About Oracle HTTP Server Security

Security can be organized into the three categories of authentication, authorization, and confidentiality. Oracle HTTP Server provides support for all three of these categories. It is based on the Apache Web server, and its security infrastructure is primarily provided by the Apache modules, mod_auth and mod_access, and the Oracle modules, mod_ossl and mod_osso. mod_auth provides authentication based on user name and password pairs, mod_access controls access to the server based on the characteristics of a request, such as hostname or IP address, mod_ossl provides confidentiality and authentication with X.509 client certificates over SSL, and mod_osso enables single sign-on authentication for Web applications.

Based on the Apache model, Oracle HTTP Server provides access control, authentication, and authorization methods that can be configured with access control directives in the httpd.conf file. When URL requests arrive at Oracle HTTP Server, they are processed in a sequence of steps determined by server defaults and configuration parameters. The steps for handling URL requests are implemented through a module or plug-in architecture that is common to many Web listeners.

Figure 10-1 shows how URL requests are handled by the server. Each step in this process is handled by a server module depending on how the server is configured. For example, if basic authentication is used, then the steps labeled "Authentication" and "Authorization" in Figure 10-1 represent the processing of the mod_auth module.

Figure 10-1 Steps for Handling URL Requests in Oracle HTTP Server

Description of ohsurlpr.gif follows
Description of the illustration ohsurlpr.gif

Classes of Users and Their Privileges

Oracle HTTP Server authorizes and authenticates users before allowing them to access, or modify resources on the server. Below are three classes of users that access the server using Oracle HTTP Server, and their privileges.

Resources Protected

Oracle HTTP Server is configured to protect resources such as:

Authentication and Authorization Enforcement

Oracle HTTP Server provides user authentication and authorization at two stages:

Host-based Access Control

Early in the request processing cycle, access control is applied, which can inhibit further processing based on the host name, IP address, or other characteristics such as browser type. You use the deny, allow, and order directives to set this type of access control. These restrictions are configured with Oracle HTTP Server configuration directives and can be based on particular files, directories, or URL formats using the <Files>, <Directory>, and <Location> container directives as shown in the Example 10-1 below:

Example 10-1 Host-based Access Control 

<Directory /internalonly/>
  order deny, allow
  deny from all
  allow from 192.168.1 us.oracle.com
</Directory>

In Example 10-1, the order directive determines the order in which Oracle HTTP Server reads the conditions of the deny and allow directives. The deny directive ensures that all requests are denied access. Then, using the allow directive, requests originating from any IP address in the 192.168.1.* range, or with the domain name us.oracle.com are allowed access to files in the directory /internalonly/. It is common practice to specify both allow and deny in host-based authentication to make the access policy explicit.

If you want to match objects at the file system level, then you must use <Directory> or <Files>. If you want to match objects at the URL level, then you must use <Location>.


Note:

Allowing or restricting access based on a host name for Internet access is not considered a very good method of providing security, because host names are easy to spoof. While the same is true of IP addresses, sabotage is more difficult. However, setting access control with intranet IP address ranges is reasonable because the same risks do not apply. This assumes that your firewalls have been properly configured.

Access Control for Virtual Hosts

To set up access control for virtual hosts, place the AccessConfig directive inside a virtual host container in the server configuration file, httpd.conf. When used in a virtual host container, the AccessConfig directive specifies an access control policy contained in a file. Example 10-2 shows an excerpt from an httpd.conf file which provides the syntax for using AccessConfig this way:

Example 10-2 Using AccessConfig to Set Up Access Control 

...
<VirtualHost ip_address_of_host.some_domain.com>
  ... virtual host directives ...
  AccessConfig conf/access.conf
</VirtualHost>

Using mod_access and mod_setenvif for Host-based Access Control

Using host-based access control schemes, you can control access to restricted areas based on where HTTP requests originate. Oracle HTTP Server uses mod_access and mod_setenvif to perform host-based access control. mod_access provides access control based on client hostname, IP address, or other characteristics of the client request, and mod_setenvif provides the ability to set environment variables based upon attributes of the request. When you enter configuration directives into the httpd.conf file that use these modules, the server fulfills or denies requests based on the address or name of the host, or based on the HTTP request header contents.

You can use host-based access control to protect static HTML pages, applications, or components.

Oracle HTTP Server supports four host-based access control schemes:

All of these allow you to specify the machines from which access to protected areas is granted or denied. Your decision to choose one or more of the host-based access control schemes is determined by which scheme most efficiently protects your restricted content and applications, or which scheme is easiest to maintain.

Controlling Access by IP Address

Controlling access with IP addresses is a preferred method of host-based access control. It does not require DNS lookups that consume time, system resources, and make your server vulnerable to DNS spoofing attacks.

Example 10-3 Controlling Access by IP Address 

<Directory /secure_only/>
  order deny,allow
  deny from all
  allow from 207.175.42.*
</Directory>

In Example 10-3, requests originating from all IP addresses except 207.175.42.* range are denied access to the /secure_only/ directory.

Controlling Access by Domain Name

Domain name-based access control can be used with IP address-based access control to solve the problem of IP addresses changing without warning. When you combine these methods, if an IP address changes, then the secure areas of your site are still protected because the domain names you want to keep out will still be denied access.

To combine domain name-based with IP address-based access control, use the syntax shown in Example 10-4:

Example 10-4 controlling Access by Domain Name 

<Directory /co_backgr/>
  order allow,deny
  allow from all
  # 141.217.24.* is the IP for malicious.cracker.com
  deny from malicious.cracker.com 141.217.24.*
</Directory>

In Example 10-4, all requests for directory /co_backgr/ are accepted except those that originate from the domain name malicious.cracker.com or the IP address 141.217.24.* range. Although this is not a fool proof precaution against domain name or IP address spoofing, it protects your site from malicious.cracker.com even if they change their IP address.

Controlling Access by Network or Netmask

You can control access based on subsets of networks, specified by IP address. The syntax is shown in Example 10-5:

Example 10-5 Controlling Access by Network or Netmask 

<Directory /payroll/>
  order deny,allow
  deny from all
  allow from 10.1.0.0/255.255.0.0
</Directory>

In Example 10-5, access is allowed from a network/netmask pair. A netmask shows how an IP address is to be divided into network, subnet, and host identifiers. Netmasks enable you to refer to only the host ID portion of an IP address.

The netmask in Example 10-5, 255.255.0.0, is the default netmask setting for a Class B address. The binary ones (decimal 255) mask the network ID and the binary zeroes (decimal 0) retain the host ID of a given IP address.

Controlling Access with Environment Variables

You can use arbitrary environment variables for access control, instead of using IP addresses or domain names. Use BrowserMatch and SetEnvIf directives for this type of access control.


Note:

Typically, BrowserMatch and SetEnvIf are not used to implement security policies. Instead they are used to provide different handling of requests based on browser types and versions.

Use BrowserMatch when you want to base access on the type of browser used to send a request. For instance, if you want to allow access only to requests that come from a Netscape browser, then use the syntax shown in Example 10-6:

Example 10-6 Controlling Access with Environment Variables 

BrowserMatch ^Mozilla netscape_browser
<Directory /mozilla-area/>
  order deny,allow
  deny from all
  allow from env=netscape_browser
</Directory>

Use SetEnvIf when you want to base access on header information contained in the HTTP request. For instance, if you want to deny access from any browsers using HTTP version 1.0 or earlier, then use the syntax shown in Example 10-7:

Example 10-7 Controlling Access with SetEnv 

SetEnvIf Request_Protocol ^HTTP/1.1 http_11_ok
<Directory /http1.1only/>
  order deny,allow
  deny from all
  allow from env=http_11_ok
</Directory>

User Authentication and Authorization

Basic authentication prompts for a user name and password before serving an HTTP request. When a browser requests a page from a protected area, Oracle HTTP Server responds with an unauthorized message (status code 401) containing a WWW-Authenticate: header and the name of the realm configured by the configuration directive, AuthName. When the browser receives this response, it prompts for a user name and password. After the user enters a user name and password combination, the browser sends this information back to the server in an Authorization header. In the authorization header message, the user name and password are encoded as a base 64 encoded string.

User authorization involves checking the authenticated user against an access control list that is associated with a specific server resource such as a file or directory. To configure user authorization, place the require directive in the httpd.conf file, usually within a virtual host container. User authorization is commonly used in combination with user authentication. After the server has authenticated a user's user name and password, then the server compares the user to an access control list associated with the requested server resource. If Oracle HTTP Server finds the user or the user's group on the list, then the resource is made available to that user.

Using mod_auth to Authenticate Users

User authentication is based on user names and passwords that are checked against a list of known users and passwords. These user name and password pairs may be stored in a variety of forms, such as a text file, database, or directory service. Then configuration directives are used in httpd.conf to configure this type of user authentication on the server. mod_auth uses the AuthUserFile directive to set up basic authentication. It supports only files.

Any authentication scheme that you devise requires that you use a combination of the configuration directives listed in Table 10-1.

Table 10-1 Directives Descriptions

Directive Name Description
AuthName Defines the name of the realm in which the user names and passwords are valid. Use quotation marks if the name includes spaces.
AuthType Specifies the authentication type. Most authentication modules use basic authentication, which transmits user names and passwords in clear text. This is not recommended.
AuthUserFile Specifies the path to a file that contains user names and passwords.
AuthGroupFile Specifies the path to a file that contains group names and their members.

Using mod_osso to Authenticate Users

mod_osso enables single-sign on for Oracle HTTP Server. mod_osso examines incoming requests and determines whether the resource requested is protected, and if so, retrieves the Oracle HTTP Server cookie for the user.

Through mod_osso, Oracle HTTP Server becomes a single sign-on (SSO) partner application enabled to use SSO to authenticate users and obtain their identity using Oracle Application Server Single Sign-On, and to make user identities available to Web applications as an Apache header variable.

Using mod_osso, Web applications can register URLs that require SSO authentication. When Oracle HTTP Server receives URL requests, mod_osso detects which requests require SSO authentication and redirects them to the SSO server. Once SSO server authenticates the users, it passes the user's authenticated identity back to mod_osso in a secure token, or cookie. mod_osso retrieves the user's identity from the cookie and propagates the user's identity information to applications running in Oracle HTTP Server instance. mod_osso can propagate the user's identity information to applications running in CGI, and those running in OC4J, and it can also authenticate users for access to static files.


See Also:


Using mod_ossl to Authenticate Users

Secure Sockets Layer (SSL) is an encrypted communication protocol that is designed to securely send messages across the Internet. It resides between Oracle HTTP Server on the application layer and the TCP/IP layer, transparently handling encryption and decryption when a secure connection is made by a client.

One common use of SSL is to secure Web HTTP communication between a browser and a Web server. This case does not preclude the use of non-secured HTTP. The secure version is simply HTTP over SSL (named HTTPS). The differences are that HTTPS uses the URL scheme https:// rather than http://, and its default communication port is 4443 on UNIX or 443 on Windows.

mod_ossl is a plug-in to Oracle HTTP Server that enables the server to use SSL. mod_ossl replaces mod_ssl in the Oracle HTTP Server distribution. Oracle no longer supports mod_ssl.


See Also:

"Using mod_ossl" for detailed information regarding mod_ossl.

Enabling SSL

By default, SSL is disabled when you install Oracle Application Server. If you want to enable SSL after installation, perform the following steps:

  1. Open opmn.xml in a text editor.

  2. In the <ias-component id=HTTP_Server> entry, change the start mode from "ssl-disabled" to "ssl-enabled". After modification is made, the entry should look like the following: 

    <data id="start-mode" value="ssl-enabled"/>

  3. Save and close opmn.xml.

  4. Reload OPMN using the following command: 

    opmnctl reload

  5. Stop Oracle HTTP Server using Application Server Control Console, or with the following command:

    • UNIX: ORACLE_HOME/opmn/bin> opmnctl [verbose] stopproc ias-component=HTTP_Server

    • Windows: ORACLE_HOME\opmn\bin> opmnctl [verbose] stopproc ias-component=HTTP_Server


      See Also:

      "Application Server Control Console"

  6. Start Oracle HTTP Server using Application Server Control Console, or with the following command:

    • UNIX: ORACLE_HOME/opmn/bin> opmnctl [verbose] startproc ias-component=HTTP_Server

    • Windows: ORACLE_HOME\opmn\bin> opmnctl [verbose] startproc ias-component=HTTP_Server


      See Also:

      "Application Server Control Console"

  7. You can verify if SSL was enabled successfully by navigating to the SSL port, for example: 

    HTTPS://hostname:4443

    Note:

    The steps above enable SSL for Oracle HTTP Server using a default insecure certificate. To achieve completely secure SSL communication with Oracle HTTP Server, obtain and configure a real certificate within mod_ossl.

Security Services Implemented Within Oracle HTTP Server

Oracle HTTP Server provides security services that enable you to protect your server from unwanted users and malicious attacks. These security services ensure secure data exchanged between client and the server.

mod_ossl enables secure connections between Oracle HTTP Server and a browser client by using an Oracle-provided encryption mechanism over SSL. It also provides data integrity and strong authentication for users and HTTP servers.

Data exchange between mod_oc4j and OC4J can be made more secure through port tunneling. Port tunneling offers a higher degree of security by allowing all communication between Oracle HTTP Server and OC4J to happen on a single port using SSL.

These security services are further discussed in the following topics:

Using mod_ossl

mod_ossl provides standard support for HTTPS protocol connections to Oracle Application Server. It enables secure connections between Oracle HTTP Server and a browser client by using an Oracle-provided encryption mechanism over SSL. It may also be used for authentication over the Internet through the use of digital certificate technology. It supports SSL v. 3.0, and provides:

  • Encrypted communication between client and server, using RSA or DES encryption standards.

  • Integrity checking of client-server communication using MD5 or SHA checksum algorithms.

  • Certificate management with Oracle wallets.

Table 10-2 identifies the differences between mod_ossl, and mod_ssl.

Table 10-2 Differences between mod_ossl and mod_ssl

Feature mod_ossl mod_ssl
SSL versions supported 3.0 2.0, 3.0, TLS 1.0
Certificate management Oracle WalletFoot 1 , Foot 2  Text file

Footnote 1 Oracle Wallet Manager is a tool that manages certificates for mod_ossl.
Footnote 2 Supports obfuscated passwords.

The mod_ssl directives listed below are not supported by mod_ossl.

  • SSLRandomSeed

  • SSLCertificateFile

  • SSLCertificateKeyFile

  • SSLCertificateChainFile

  • SSLCACertificateFile

  • SSLCACertificatePath

  • SSLVerifyDepth


    Note:

    The server will not start if these directives are used.

Using mod_ossl Directives

To configure SSL for your Oracle HTTP Server, enter the mod_ossl directives you want to use in the httpd.conf file.

The following directive are described below:

SSLAccelerator  Specifies if SSL accelerator is used. Currently only nFast card is supported.
Category Value
Valid Values yes/no
Syntax SSLAccelerator yes|no
Default SSLAccelerator no
Context server configuration

SSLCARevocationFile  Specifies the file where you can assemble the Certificate Revocation Lists (CRLs) from CAs (Certificate Authorities) that you accept certificates from. These are used for client authentication. Such a file is the concatenation of various PEM-encoded CRL files in order of preference. This directive can be used alternatively or additionally to SSLCARevocationPath.
Category Value
Syntax SSLCARevocationFile file_name
Example SSLCARevocationFile /ORACLE_HOME/Apache/conf/ssl.crl/ca_bundle.crl
Default None
Context server configuration, virtual host

SSLCARevocationPath  Specifies the directory where PEM-encoded Certificate Revocation Lists (CRLs) are stored. These CRLs come from the CAs (Certificate Authorities) that you accept certificates from. If a client attempts to authenticate itself with a certificate that is on one of these CRLs, then the certificate is revoked and the client cannot authenticate itself with your server.
Category Value
Syntax SSLCARevocationPath path/to/CRL_directory/
Example SSLCARevocationPath /ORACLE_HOME/Apache/conf/ssl.crl/
Default None
Context server configuration, virtual host

SSLCipherSuite  Specifies the SSL cipher suite that the client can use during the SSL handshake. This directive uses a colon-separated cipher specification string to identify the cipher suite. Table 10-3 shows the tags you can use in the string to describe the cipher suite you want.

Tags are joined together with prefixes to form cipher specification string.

Category Value
Valid Values none: Adds the cipher to the list

+ : Adds the cipher to the list and place them in the correct location in the list

- : Remove the cipher from the list (can be added later)

! : Remove the cipher from the list permanently

Example SSLCipherSuite ALL:!LOW:!DH

In this example, all ciphers are specified except low strength ciphers and those using the Diffie-Hellman key negotiation algorithm.

Syntax SSLCipherSuite cipher-spec

Default None
Context server configuration, virtual host, directory

Table 10-3 SSLCipher Suite Tags

Function Tag Meaning
Key exchange kRSA RSA key exchange
Key exchange kDHr Diffie-Hellman key exchange with RSA key
Authentication aNULL No authentication
Authentication aRSA RSA authentication
Authentication aDH Diffie-Hellman authentication
Encryption eNULL No encryption
Encryption DES DES encoding
Encryption 3DES Triple DES encoding
Encryption RC4 RC4 encoding
Data Integrity MD5 MD5 hash function
Data Integrity SHA SHA hash function
Aliases SSLv3 All SSL version 3.0 ciphers
Aliases EXP All export ciphers
Aliases EXP40 All 40-bit export ciphers only
Aliases EXP56 All 56-bit export ciphers only
Aliases LOW All low strength ciphers (export and single DES)
Aliases MEDIUM All ciphers with 128-bit encryption
Aliases HIGH All ciphers using triple DES
Aliases RSA All ciphers using RSA key exchange
Aliases DH All ciphers using Diffie-Hellman key exchange


Note:

There are restrictions if export versions of browsers are used. Oracle module, mod_ossl, supports RC4-40 encryption only when the server uses 512 bit key size wallets.

Table 10-4 Cipher Suites Supported in Oracle Advanced Security 9i

Cipher Suite Authentication Encryption Data Integrity
SSL_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES EDE CBC SHA
SSL_RSA_WITH_RC4_128_SHA RSA RC4 128 SHA
SSL_RSA_WITH_RC4_128_MD5 RSA RC4 128 MD5
SSL_RSA_WITH_DES_CBC_SHA RSA DES CBC SHA
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA DH anon 3DES EDE CBC SHA
SSL_DH_anon_WITH_RC4_128_MD5 DH anon RC4 128 MD5
SSL_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES EDE CBC SHA
SSL_DH_anon_WITH_DES_CBC_SHA DH anon DES CBC SHA
SSL_RSA_EXPORT_WITH_RC4_40_MD5 RSA RC4 40 MD5
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA RSA DES40 CBC SHA
SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 DH anon RC4 40 MD5
SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA DH anon DES40 CBC SHA

SSLEngine  Toggles the usage of the SSL Protocol Engine. This is usually used inside a <VirtualHost> section to enable SSL for a particular virtual host. By default, the SSL Protocol Engine is disabled for both the main server and all configured virtual hosts. Example 10-8 is an example for using SSLEngine directive. The default SSL is 4443 on UNIX and 443 on Windows.

Example 10-8 Using SSLEngine Directive 

<VirtualHost_dafault_:4443>
  SSLEngine on
  ...
</VirtualHost>
Category Value
Syntax SSLEngine on|off
Default SSLEngine off
Context server configuration, virtual host

SSLLog  Specifies where the SSL engine log file will be written. (Error messages will also be duplicated to the standard Oracle HTTP Server log file specified by the ErrorLog directive.)

Place this file at a location where only root can write, so that it cannot be used for symlink attacks. If the filename does not begin with a slash (/), it is assumed to be relative to the ServerRoot. If the filename begins with a bar (|), then the string following the bar is expected to be a path to an executable program to which a reliable pipe can be established.

This directive should occur only once per virtual server configuration.

Category Value
Syntax SSLVerifyClient path/to/filename
Default None
Context server configuration, virtual host

SSLLogLevel  Specifies the verbosity degree of the SSL engine log file.
Category Value
Valid Values The levels are (in ascending order, where each level is included in the levels above it):

  • none: No dedicated SSL logging is done. Messages of type 'error' are duplicated to the standard HTTP server log file specified by the ErrorLog directive.

  • error: Only messages of the type 'error' (conditions that stop processing) are logged.

  • warn: Messages that notify of non-fatal problems (conditions that do not stop processing) are logged.

  • info: Messages that summarize major processing actions are logged.

  • trace: Messages that summarize minor processing actions are logged.

  • debug: Messages that summarize development and low-level I/O operations are logged.

Syntax SSLLogLevel level
Default None
Context server configuration, virtual host

SSLMutex  Type of semaphore (lock) for SSL engine's mutual exclusion of operations that have to be synchronized between Oracle HTTP Server processes.
Category Value
Valid Values
  • none: Uses no mutex at all. Not recommended, because the mutex synchronizes the write access to the SSL session cache. If you do not configure a mutex, the session cache can become garbled.

  • file:path/to/mutex: Uses a file for locking. The process ID (PID) of the Oracle HTTP Server parent process is appended to the filename to ensure uniqueness. If the filename does not begin with a slash (/), it is assumed to be relative to ServerRoot. This setting is not available on Windows.

  • sem: Uses an operating system semaphore to synchronize writes. On UNIX, it would be a Sys V IPC semaphore; on Windows, it is a Windows Mutex. This is the best choice, if the operating system supports it.

Example SSLMutex file:/usr/local/apache/logs/ssl_mutex
Syntax SSLMutex type
Default SSLMutex none
Context server configuration

SSLOptions  Controls various runtime options on a per-directory basis. In general, if multiple options apply to a directory, the most comprehensive option is applied (options are not merged). However, if all of the options in an SSLOptions directive are preceded by a plus ('+') or minus ('-') symbol, then the options are merged. Options preceded by a plus are added to the options currently in force, and options preceded by a minus are removed from the options currently in force.
Category Value
Valid Values
  • StdEnvVars: Creates the standard set of CGI/SSI environment variables that are related to SSL. This is disabled by default because the extraction operation uses a lot of CPU time and usually has no application when serving static content. Typically, you only enable this for CGI/SSI requests.

  • ExportCertData: Enables the following additional CGI/SSI variables:

    SSL_SERVER_CERT

    SSL_CLIENT_CERT

    SSL_CLIENT_CERT_CHAIN_n (where n= 0, 1, 2...)

    These variables contain the Privacy Enhanced Mail (PEM)-encoded X.509 certificates for the server and the client for the current HTTPS connection, and can be used by CGI scripts for deeper certificate checking. All other certificates of the client certificate chain are provided. This option is "Off" by default because there is a performance cost associated with using it.

    SSL_CLIENT_CERT_CHAIN_n variables are in the following order: SSL_CLIENT_CERT_CHAIN_0 is the intermediate CA who signs SSL_CLIENT_CERT. SSL_CLIENT_CERT_CHAIN_1 is the intermediate CA who signs SSL_CLIENT_CERT_CHAIN_0, and so forth, with SSL_CLIENT_ROOT_CERT as the root CA.

  • FakeBasicAuth: Translates the subject distinguished name of the client X.509 certificate into an HTTP basic authorization user name. This means that the standard HTTP server authentication methods can be used for access control. Note that no password is obtained from the user; the string 'password' is substituted.

Valid Values (for SSLOptions continued)
  • StrictRequire: Denies access when, according to SSLRequireSSL or directives, access should be forbidden. Without StrictRequire, it is possible for a 'Satisfy any' directive setting to override the SSLRequire or SSLRequireSSL directive, allowing access if the client passes the host restriction or supplies a valid user name and password.

    Thus, the combination of SSLRequireSSL or SSLRequire with SSLOptions +StrictRequire gives mod_ossl the ability to override a 'Satisfy any' directive in all cases.

  • CompatEnvVars: Exports obsolete environment variables for backward compatibility to Apache SSL 1.x, mod_ssl 2.0.x, Sioux 1.0, and Stronghold 2.x. Use this to provide compatibility to existing CGI scripts.

  • OptRenegotiate: This enables optimized SSL connection renegotiation handling when SSL directives are used in a per-directory context.

Syntax SSLOptions [+-] option
Default None
Context server configuration, virtual host, directory

SSLPassPhraseDialog  Type of pass phrase dialog for wallet access. mod_ossl asks the administrator for a pass phrase in order to access the wallet.
Category Value
Valid Values
  • builtin: when the server is started, mod_ossl prompts for a password for each wallet.

    This cannot be used when Oracle HTTP Server is managed by OPMN. No user interaction is allowed when Oracle HTTP Server is started by OPMN.

  • exec:path/to/program - when the server is started, mod_ossl calls an external program configured for each wallet. This program is invoked with two arguments: servername:portnumber and RSA or DSA.

Syntax SSLPassPhraseDialog type
Example SSLPassPhraseDialog exec:/usr/local/apache/sbin/pfilter
Default SSLPassPhraseDialog builtin
Context server configuration

SSLProtocol  Specifies SSL protocol(s) for mod_ossl to use when establishing the server environment. Clients can only connect with one of the specified protocols.
Category Value
Valid Values SSLv3

SSL version 3.0

Example To specify only SSL version 3.0, set this directive to the following:

SSLProtocol +SSLv3

Syntax SSLProtocol [+-] protocol
Default SSLProtocol +SSLv3
Context server configuration, virtual host

SSLRequire  Denies access unless an arbitrarily complex boolean expression is true. The expression must match the syntax below (given as a BNF grammar notation):
Category Value
  
expr ::= "true" | "false"
"!" expr
expr "&&" expr
expr "||" expr
"(" expr ")"
  
comp ::=word "==" word | word "eq" word
word "!=" word |word "ne" word
word "<" word |word "lt" word
word "<=" word |word "le" word
word ">" word |word "gt" word
word ">=" word |word "ge" word
word "=~" regex
word "!~" regex
wordlist ::= word
wordlist "," word
  
word ::= digit
cstring
variable
function
  
digit ::= [0-9]+
  
cstring ::= "..."
  
variable ::= "%{varname}"
Table 10-5 and Table 10-6 list standard and SSL variables. These are valid values for varname.
  
function ::= funcname "(" funcargs ")"
For funcname, the following function is available: 
file(filename)

The file function takes one string argument, the filename, and expands to the contents of the file. This is useful for evaluating the file's contents against a regular expression.

Syntax SSLRequire expression
Default None
Context directory

Table 10-5 lists the standard variables for SSLRequire varname.

Table 10-5 Standard Variables for SSLRequire Varname

Standard Variables Standard Variables Standard Variables
HTTP_USER_AGENT PATH_INFO AUTH_TYPE
HTTP_REFERER QUERY_STRING SERVER_SOFTWARE
HTTP_COOKIE REMOTE_HOST API_VERSION
HTTP_FORWARDED REMOTE_IDENT TIME_YEAR
HTTP_HOST IS_SUBREQ TIME_MON
HTTP_PROXY_CONNECTION DOCUMENT_ROOT TIME_DAY
HTTP_ACCEPT SERVER_ADMIN TIME_HOUR
HTTP:headername SERVER_NAME TIME_MIN
THE_REQUEST SERVER_PORT TIME_SEC
REQUEST_METHOD SERVER_PROTOCOL TIME_WDAY
REQUEST_SCHEME REMOTE_ADDR TIME
REQUEST_URI REMOTE_USER ENV:variablename
REQUEST_FILENAME  
 

Table 10-6 lists the SSL variables for SSLRequire varname.

Table 10-6 SSL Variables for SSLRequire Varname

SSL Variables SSL Variables SSL Variables
HTTPS SSL_PROTOCOL SSL_CIPHER_ALGKEYSIZE
SSL_CIPHER SSL_CIPHER_EXPORT SSL_VERSION_INTERFACE
SSL_CIPHER_USEKEYSIZE SSL_VERSION_LIBRARY SSL_SESSION_ID
SSL_CLIENT_V_END SSL_CLIENT_M_SERIAL SSL_CLIENT_V_START
SSL_CLIENT_S_DN_ST SSL_CLIENT_S_DN SSL_CLIENT_S_DN_C
SSL_CLIENT_S_DN_CN SSL_CLIENT_S_DN_O SSL_CLIENT_S_DN_OU
SSL_CLIENT_S_DN_G SSL_CLIENT_S_DN_T SSL_CLIENT_S_DN_I
SSL_CLIENT_S_DN_UID SSL_CLIENT_S_DN_S SSL_CLIENT_S_DN_D
SSL_CLIENT_I_DN_C SSL_CLIENT_S_DN_Email SSL_CLIENT_I_DN
SSL_CLIENT_I_DN_O SSL_CLIENT_I_DN_ST SSL_CLIENT_I_DN_L
SSL_CLIENT_I_DN_T SSL_CLIENT_I_DN_OU SSL_CLIENT_I_DN_CN
SSL_CLIENT_I_DN_S SSL_CLIENT_I_DN_I SSL_CLIENT_I_DN_G
SSL_CLIENT_I_DN_Email SSL_CLIENT_I_DN_D SSL_CLIENT_I_DN_UID
SSL_CLIENT_CERT SSL_CLIENT_CERT_CHAIN_n SSL_CLIENT_ROOT_CERT
SSL_CLIENT_VERIFY SSL_CLIENT_M_VERSION SSL_SERVER_M_VERSION
SSL_SERVER_V_START SSL_SERVER_V_END SSL_SERVER_M_SERIAL
SSL_SERVER_S_DN_C SSL_SERVERT_S_DN_ST SSL_SERVER_S_DN
SSL_SERVER_S_DN_OU SSL_SERVER_S_DN_CN SSL_SERVER_S_DN_O
SSL_SERVER_S_DN_I SSL_SERVER_S_DN_G SSL_SERVER_S_DN_T
SSL_SERVER_S_DN_D SSL_SERVER_S_DN_UID SSL_SERVER_S_DN_S
SSL_SERVER_I_DN SSL_SERVER_I_DN_C SSL_SERVER_S_DN_Email
SSL_SERVER_I_DN_L SSL_SERVER_I_DN_O SSL_SERVER_I_DN_ST
SSL_SERVER_I_DN_CN SSSL_SERVER_I_DN_T SSL_SERVER_I_DN_OU
SSL_SERVER_I_DN_G SSL_SERVER_I_DN_I  

SSLRequireSSL  Denies access to clients not using SSL. This is a useful directive for absolute protection of a SSL-enabled virtual host or directories in which configuration errors could create security vulnerabilities.
Category Value
Syntax SSLRequireSSL
Default None
Context directory

SSLSessionCache  Specifies the global/interprocess session cache storage type. The cache provides an optional way to speed up parallel request processing.
Category Value
Valid Values
  • none: disables the global/interprocess session cache. Produces no impact on functionality, but makes a major difference in performance.

  • shmht:/path/to/datafile[bytes]: Uses a high-performance hash table (bytes specifies approximate size) inside a shared memory segment in RAM, which is established by the /path/to/datafile. This hash table synchronizes the local SSL memory caches of the server processes.

  • shmcb:/path/to/datafile[bytes]: Uses a high-performance Shared Memory Cyclic Buffer (SHMCB) session cache to synchronize the local SSL memory caches of the server processes. The performance of shmcb is more uniform in all environments when compared to shmht.

Syntax SSLSessionCache type
Examples SSLSessionCache shmht: /ORACLE_HOME/Apache/Apache/logs/ssl_scache(512000)

SSLSessionCache shmcb: /ORACLE_HOME/Apache/Apache/logs/ssl_scache(512000)

Default SSLSessionCache none

SSLSessionCacheTimeout  Specifies the number of seconds before a SSL session in the session cache expires.
Category Value
Syntax SSLSessionCacheTimeout seconds
Default 300
Context server configuration

SSLVerifyClient  Specifies whether or not a client must present a certificate when connecting.
Category Value
Valid Values
  • none: No client certificate is required

  • optional: Client may present a valid certificate

  • require: Client must present a valid certificate

Syntax SSLVerifyClient level
Default None
Context server configuration, virtual host


Note:

The level optional_no_ca included with mod_ssl (in which the client can present a valid certificate, but it need not be verifiable) is not supported in mod_ossl.

SSLWallet  Specifies the location of the wallet with its WRL.
Category Value
Syntax SSLWallet wrl

The format of wrl is: file:path to wallet

Example SSLWallet file:/etc/ORACLE/WALLETS/server

Other values of wrl may be used as permitted by the Oracle SSL product.

Default None
Context server configuration, virtual host

SSLWalletPassword  Specifies the Wallet password needed to access the wallet specified within the same context. You can choose either a cleartext wallet password or an obfuscated password. The obfuscated password is created with the command line tool iasobf. If you must use a regular wallet, Oracle recommends that you use the obfuscated password instead of a cleartext password.

See Also:

"Using the iasobf Utility"

Category Value
Syntax SSLWalletPassword password

If no password is required do not set this directive.

Note: If a wallet created with the Auto Login feature of Oracle Wallet Manager is used, then do not set this directive because these wallets do not require passwords.

Default None
Context server configuration, virtual host


Note:

SSLWalletPassword has been deprecated. A warning message is generated in the Oracle HTTP Server log if this directive is used. For secure wallets, Oracle recommends that you get a SSO wallet instead. Refer to the Oracle Application Server 10g Security Guide for information on SSO wallet.

Using mod_proxy Directives

The following directives are for mod_proxy support only:

SSLProxyCache  Specifies whether the proxy cache will be used. The proxy will use the same session as the SSL server uses.
Category Value
Syntax SSLProxyCache on/off
Default SSLProxyCache off
Context server configuration, virtual host

SSLProxyCipherSuite  Specifies the proxy server's cipher suite.
Category Value
Syntax SSLCipherSuite cipher-spec
Default None
Context server configuration, virtual host

SSLProxyProtocol  Controls the proxy server's SSL protocol flavors.
Category Value
Syntax SSLProxyProtocol [+-] protocol
Default None
Context server configuration, virtual host

SSLProxyWallet  Specifies the location of the wallet containing the certificates to use when opening proxy connections.
Category Value
Syntax SSLProxyWallet wrl
Default None
Context server configuration, virtual host

SSLProxyWalletPassword  Specifies the proxy wallet password.
Category Value
Syntax SSLProxyWalletPassword password
Default None
Context server configuration, virtual host


Note:

SSLProxyWalletPassword has been deprecated. A warning message is generated in the Oracle HTTP Server log if this directive is used. For secure wallets, Oracle recommends that you get a SSO wallet instead. Refer to the Oracle Application Server 10g Security Guide for information on SSO wallet.

Using mod_ossl Directives to Configure Client Authentication

This section provides instructions on how you can use the directives mentioned above to set up configurations that enable you to use client certificates for authenticating clients. Below are some scenarios:

  • Authenticating clients based on certificates when all clients are known.

    The server wallet has imported the CA certificate which signed all the client certificates.

    For example, specify the following directives in the httpd.conf file: 

    SSLVerifyClient require

  • Authenticating for a particular URL based on certificates, while allowing arbitrary clients to access the rest of the server

    To enable this, use the per-directory reconfiguration feature of mod_ossl. Session re-negotiation allows an SSL session to be re-negotiated with a client after the initial request and URL have been read. This is only supported for requests that do not contain body data, such as GET requests.


    See Also:


    For example, specify the following directives in the httpd.conf file: 

    <Location /secure/area>

      SSLVerifyClient require

</Location>

Using the iasobf Utility

The iasobf utility enables you to generate an obfuscated wallet password from a cleartext password.

If you are using an Oracle Wallet that has been created with Auto Login enabled (an SSO wallet), then you do not need to use this utility. However, if you must use a regular wallet with a password, then Oracle recommends that you use the password obfuscation tool iasobf, which is located in ORACLE_HOME/Apache/Apache/bin, to generate an obfuscated wallet password from a cleartext password.

To generate an obfuscated wallet password, the command syntax is: 

iasobf -p password

The obfuscated password is printed to the terminal. The arguments are optional. If you do not type them, the tool will prompt you for the password.


Note:

The corresponding tool for Windows environments is called osslpassword, which can be used in the same way as iasobf.

Understanding Port Tunneling

Port tunneling allows all communication between Oracle HTTP Server and OC4J to happen on a single, or a small number of ports. Previously, the firewall configuration had to include port information for several ports to handle communication between Oracle HTTP Server and multiple OC4J instances. Using port tunneling, a daemon called iaspt routes requests to the appropriate OC4J instances. Only one, or a small number of ports have to be opened through the firewall regardless of the number of OC4J instances involved, thereby offering a higher degree of security for the communication between Oracle HTTP Server and OC4J.

To enable this, a de-militarized zone environment is provided where a firewall exists typically between the client and the Oracle HTTP Server, and another that exists between Oracle HTTP Server and OC4J. In this configuration, Oracle HTTP Server exists in the DMZ bracketed by the two firewalls. OC4J, and other business logic components, exist behind both firewalls in the intranet. To ensure the highest degree of security, all communication transmitted between machines is encrypted using SSL. Port tunneling provides the framework to support this level of security in a flexible, manageable manner, which enhances performance.

The suggested port range is 7501-7599, the default being 7501, but you can select a port of your choice.

Figure 10-2 Port Tunneling

Description of newseca.gif follows
Description of the illustration newseca.gif

Figure 10-2 shows an Oracle Application Server configuration using port tunneling. The iaspt daemon, a stand-alone component, acts as a communication concentrator for connections between Oracle HTTP Server and the Java Virtual Machine (JVM), which contains OC4J. Oracle HTTP Server does not connect directly to OC4J. Instead, it connects to the iaspt daemon which then dispatches communication on to OC4J. By doing this concentration of connections, only one port is opened per port tunneling on the internal firewall, instead of one port per OC4J instance.

The communication between Oracle HTTP Server and the iaspt daemon is encrypted using SSL. Authentication is enabled when these connections are established using SSL Client Certificates. These connections are persistent, and are maintained for a reasonable time depending on connection resources. The AJP 1.3 protocol, modified to include routing information that indicates which servlet engine a request is to be routed to, is used.

Port tunneling supports connections between Oracle HTTP Server and OC4J. To support OC4J, Oracle HTTP Server module mod_oc4j is modified to use SSL encrypted communication and to route requests through the port tunneling processes. Port tunneling supports static configurations.

There must be at least one iaspt daemon per machine. More than one iaspt daemon can be run for higher availability. Oracle HTTP Server supports round robin partitioning of requests across iaspt daemons, and support application partitioning. Oracle HTTP Server also supports automatic failover of requests which cannot be sent to a given iaspt daemon.

Configuring Port Tunneling

The sections below contain instructions for configuring port tunneling on your machine. Topics discussed are:

Configuration Files

Port tunneling impacts several configuration files. The following configuration files require modification:

opmn.xml  Describes the processes that OPMN manages within an Oracle Application Server installation.

See Also:

"opmn.xml" on page D-7 for more details, including location.

As part of port tunneling, an entry that describes the iaspt daemon process to be started should exist in OPMN. This entry describes the following:

  • number of iaspt daemon processes to start.

  • ports that these processes can use.


    See Also:

    "Configuring iaspt.conf" section contains detailed information about adding this entry.

An out of the box Oracle Application Server installation contains an iaspt component in opmn.xml, but it is disabled by default.

mod_oc4j.conf  Configures mod_oc4j within Oracle HTTP Server.

See Also:

"mod_oc4j.conf" for more details, including location.

For port tunneling, you need to add the directives that specify the following:

  • whether port tunneling should be used

  • static location for an iaspt daemon process

  • location of SSL certificates to be used in establishing connections with the iaspt daemon processes.


    See Also:

    "Configuring iaspt.conf" section contains detailed information about adding these directives.

iaspt.conf  Configures port tunneling.

See Also:

"iaspt.conf" for more details, including location.

It specifies the following information:

  • Wallet file and password that should be used

  • Log file location and log level

  • Port that iaspt daemon should listen on (optionally). This port can either be specified in iaspt.conf, or can be passed in from opmn.xml by specifying a range of ports. By doing so, more than one port tunneling process can use the same iaspt.conf file.

Configuring iaspt.conf

The iaspt.conf file is a set of name value pairs. The names of the parameters accepted are described below:

wallet-file  Specifies the location of an Oracle Wallet file that contains SSL certificates that are used for SSL communication with peers.
Category Value
Parameter Name wallet-file
Parameter Type string
Valid Values Path to a wallet file that contains the SSL certificate to be used when establishing SSL connections to other processes.
Default Value N/A
Syntax Valid filename

For example: /foo/bar/myfilename


wallet-password  Specifies the value of the obfuscated password used for authentication when opening the wallet file. This value is obtained using the utility provided with Oracle Wallet Manager.
Category Value
Parameter Name wallet-password
Parameter Type string
Valid Values Obfuscated password used for authentication when opening the wallet file specified by wallet-file
Default Value N/A


See Also:

Oracle Application Server 10g Security Guide for information on Oracle Wallet Manager.

log-file  Specifies the path to a log file where iaspt daemon logging messages are written to.
Category Value
Parameter Name log-file
Parameter Type string
Valid Values Path to a log file where iaspt daemon logging messages are written to.
Default Value N/A
Syntax Valid filename

For example: /foo/bar/myfilename


log-level  Specifies the logging level where 9 is the highest and 0 implies no logging.
Category Value
Parameter Name log-level
Parameter Type integer
Valid Values Integer from 0 to 9
Default Value 3

iaspt-port  Specifies the port value that the iaspt daemon should accept connections on. This is optional.
Category Value
Parameter Name iaspt-port
Parameter Type integer
Valid Values Valid TCP/IP port value
Syntax Integer

For example: 9898

Default Value N/A

Configuration mod_oc4j

Perform the following steps to configure mod_oc4j to use port tunneling:

By default, mod_oc4j communicates directly to OC4J. For port tunneling process, mod_oc4j should communicate to OC4J through the iaspt daemon.

Use the directives below to connect mod_oc4j to the iaspt daemon:

Oc4jiASPTActive  Indicates whether mod_oc4j needs to consider port tunneling when routing requests. This should not be configured to "On" if Oc4jEnableSSL is configured to "On". To enable port tunneling process, set this directive to "On".
Category Value
Parameter Name Oc4jiASPTActive
Parameter Type string
Valid Values On/Off
Default Value Off

Oc4jiASPTProcess  Describes the listening host and port of a port tunneling process. There can be multiple of these lines within a mod_oc4j.conf file for multiple port tunneling processes.

As specified below, the syntax for this directive is host:port. The host value should match the value of the location where an iaspt daemon listens on. The port value should match the value configured in opmn.xml iaspt port. Both regular hostname and IP address is allowed in the host.

Category Value
Parameter Name Oc4jiASPTProcess
Parameter Type string
Valid Values host:port values of the available iaspt daemons.
Default Value N/A
Syntax host:port

For example: myhost.us.oracle.com:6667


Configuring mod_oc4j to Use SSL

mod_oc4j should use SSL when communicating with the iaspt daemon. To enable this, add the following directives to the mod_oc4j.conf file:

Oc4jiASPTWalletFile  Specifies the location of an Oracle Wallet file that contains SSL certificates that are used for SSL communication with the iaspt daemon.
Category Value
Parameter Name Oc4jiASPTWalletFile
Parameter Type string
Valid Values Path to a wallet file that contains the SSL certificate to be used when establishing SSL connections to the iaspt daemon.
Default Value N/A
Syntax Valid filename

For example: /foo/bar/myfilename


Oc4jiASPTWalletPassword  Specifies the value of the obfuscated password used for authentication when opening the wallet file. This value is obtained using the utility provided with Oracle Wallet Manager.
Category Value
Parameter Name Oc4jiASPTWalletPassword
Parameter Type: string
Valid Values Obfuscated password used for authentication when opening the wallet file specified by Oc4jSSLWalletFile
Default Value N/A


See Also:

Oracle Application Server 10g Security Guide for information on Oracle Wallet Manager.

Configuring iaspt Daemon in opmn.xml

Below are examples of how the iaspt daemon component is configured in opmn.xml.

Example 10-9 Process Module Configuration

This is an example of the configuration required to load and use the module effectively. Processes managed by this module identify the module by module ID. 

<module path="/ORACLE_HOME/opmn/lib/libopmniaspt.so">
  <module-id id="IASPT" /> 
</module>

Example 10-10 Minimum Configuration

This is an example of the smallest possible configuration for the iaspt daemon. Reasonable defaults are assigned to all other configuration elements/attributes that can be used with this component. 

<ias-component id="IASPT">
  <process-type id="IASPT" module-id="IASPT">
    <process-set id="IASPT" numprocs="1"/> 
  </process-type> 
</ias-component>

Example 10-11 Full Configuration

This is a complete example configuration for the iaspt daemon. It contains all possible configuration elements/attributes that can be used with this component. 

<module path="/ORACLE_HOME/opmn/lib/libopmniaspt"> 
  <module-id id="IASPT" /> 
</module> 
<ias-component id="IASPT" status="enabled" id-matching="false">
  <process-type id="IASPT" module-id="IASPT"> 
    <port id="ajp" range="6701-6703"/>
    <process-set id="IASPT" restart-on-death="true" numprocs="3"/>
  </process-type> 
</ias-component>

Table 10-7 contains information about the values specified in Example 10-9, Example 10-10, and Example 10-11.

Table 10-7 opmn.xml Value Description

Value Description Requirement Valid Value Default Value Path
id= "IASPT" This name is required and cannot be changed to anything else. It must match targets.xml or else Application Server Control Console will not work. true IASPT N/A ias-component
module-id= "IASPT" This name defines the type of process and associates this configuration with OPMN's port tunneling module. true IASPT N/A ias-component/process-type
numproc="3" This attribute tells how many port tunneling processes to be started. If the value is 1, no ajp/range has to be configured in port's property. The port number defined in iaspt.conf is used if there is no ajp/range configured. If the value is greater than 1, ajp/range has to be configured to specify enough ports for each iaspt daemon process. true Any number N/A ias-component/process-type/process-set
port id="ajp" This should be used together with range in port property to specify the ajp ports to be used by iaspt daemons. If it is specified, the port number configured in iaspt.conf file will be overwritten. false ajp

N/A

ias-component/process-type/process-set
port range="6701-6703" This should be used together with ID in port property to specify the ajp ports to be used by iaspt daemons. If numprocs is specified to be more than 1, a range of ports has to be configured. If no port is configured in opmn.xml (in this case, numprocs must be 1), the port number defined in iaspt.conf will be used. false Any single port or a range of ports N/A

ias-component/process-type/process-set


In opmn.xml,

  1. Change the status of the following entry from "disabled" to "enabled". 

        <ias-component id="iaspt" status="disabled">

  2. Be sure that the port in the entry below matches the port specified in mod_oc4j.conf: 

        <port id="ajp" range="7501-7600"/>

Note:

The port specified in opmn.xml has higher priority than the port specified in the iaspt-port entry of iaspt.conf.

Configuring OC4J

By default, OC4J does not require any modifications for port tunneling process. Optionally, if you want to the communication between iaspt daemon and OC4J to use SSL, do the following:

Enabling SSL for iaspt Daemon  You can enable SSL for iaspt daemon by opening iaspt.conf in a text editor and uncommenting, and changing the following entry from "false" to "true". 
destination-ssl=false

This entry determines whether SSL should be used between iaspt daemon and OC4J.

Enabling SSL for OC4J  You can enable SSL for OC4J by editing web-site.xml and using Keytool.

Note:

web-site.xml refers to the file that the web-site element in server.xml points to server.xml is the top level configuration file for OC4J. It usually resides in:

  • UNIX: ORACLE_HOME/j2ee/home/config

  • Windows: ORACLE_HOME/j2ee/home/config


Server Authentication: This section pertains to the authentication of OC4J by the client. To make the client, for example mod_oc4j, authenticate the server (OC4J), the certificate of the CA that signs OC4J's certificate must be imported into the wallet used by mod_oc4j.

  • Configuration File Extensions: The AJP Web site declaration in web-site.xml is extended to support the additional marked bold characters. 

    <web-site display-name="Oracle 9iAS Containers for J2EE HTTP web site"
protocol="ajp13" secure="true">
  <default-web-app application="default" name="defaultWebApp" />
  <access-log path="../log/default-web-access.log" /
  <ssl-config keystore="keystore" keystore-password="welcome"/>
</web-site>

    Here, the secure="true" attribute instructs the AJP 1.3 protocol to use a SSL socket. When secure is set to "true", then the ssl-config element must be specified too.

    The identity of OC4J, for the Web site described in the configuration, is stored in a file as per the keystore format. The keystore attribute points to this file. If it is not present as a relative path (not beginning with "/"), it is relative to the directory where server.xml is located.

Client Authentication by the Server: Optionally, the server can be configured to accept or reject clients (that is, client connecting through AJP/SSL) based on their identity. In this mode, the server explicitly requests client authentication. The client authenticates by sending a certificate chain. Ultimately, the chain ends with a root certificate. The server can be configured to accept a list of root certificates, thus establishing a chain of trust back to the client.

  • Configuration File Extensions: The following configuration extensions in web-site.xml are defined as follows: 

    <web-site display-name="Oracle 9iAS Containers for J2EE HTTP web site"
protocol="ajp13" secure="true"
  <default-web-app application="default" name="defaultWebApp" />
  <access-log path="../log/default-web-access.log" />

<ssl-config keystore="keystore" keystore-password="welcome"     needs-client-auth="true">

      </ssl-config>

</web-site>

needs-client-auth instructs OC4J to request the client certificate chain upon connection. If OC4J recognizes the client certificate, it proceeds to traverse the chain up to the root certificate. If the root certificate is recognized as well, then the client is accepted.

The specified keystore must contain the certificates of the clients that are authorized to connect to OC4J through AJP/SSL.

  • Managing a Keystore: Keystore is a protected database that holds keys and certificates for an enterprise. Access to a keystore is guarded by a password (defined at the time the keystore is created, by the person who creates the keystore, and changeable only when provided with the current password). In addition, each private key in a keystore can be guarded by its own password.

    Keytool is a key and certificate management utility. Use keytool to manage your keystore, for example to

    • create public/private key pairs.

    • issue certificate requests (which you send to the appropriate Certification Authority).

    • import certificate replies (obtained from the Certification Authority you contacted).

    • designate public keys belonging to other parties as trusted.


      See Also:

      http://java.sun.com for information on keystore and keytool.

  • OC4J Identity: OC4J certificate can be generated using the JDK keytool program. To generate a self-signed certificate: 

    keytool -genkey -keyalg rsa -keystore myKeystoreFile -storepass
mypassword -alias www.mysite.com -dname 'cn=www.mysite.com, ou=myUnit,
o=myOrg, l=myLocality, c=myCountry'

    Using keytool, a certification request can then be made for the self-signed certificate to any CA. This example generates a certificate request into a file that can be used with a CA. 

    keytool -certreq -rfc  -keystore myKeystoreFile -storepass -alias
www.mysite.com -file reqfile

    The CA generated certificate chain will then be imported and replaced by the self-signed one. If the certificate is stored into certfile, the command is as follows: 

    keytool -import -keystore myKeystoreFile -storepass -alias
www.mysite.com -file certfile

  • Trusted CAs: The public keys, packaged as certificates, of the trusted CAs are well known and publicly available. You can obtain such a certificate using the Certification Authority Web site. Once the CA certificate is obtained, import it into the keystore using: 

    keytool -import -keystore myKeystoreFile -storepass -alias
www.mysite.com -file certfile

  • Clients: When needs-client-auth is set to "true", the client certificate has to be either a trusted CA certificate, or be signed by a trusted CA.

Leveraging Oracle Identity Management Infrastructure

This section discusses how Oracle HTTP Server uses the Oracle Identity Management Infrastructure.

Overview

Oracle Identity Management is an integrated infrastructure that the Oracle Application Server relies on for distributed security. It consists of Oracle Internet Directory, Oracle Directory Integration and Provisioning, Delegated Administrative Service, Oracle Application Server Single Sign-On, and Oracle Certificate Authority.


See Also:

Oracle Identity Management Concepts and Deployment Planning Guide for detailed information regarding Oracle Identity Management and its components.

Using Oracle Application Server Single Sign-On and mod_osso

Oracle Application Server supports single sign-on (SSO) to Web-based applications through Oracle Application Server Single Sign-On. Oracle Application Server Single Sign-On enables you to log in to Oracle Application Server and gain access to those applications for which you have authorization for, without requiring to re-enter a user name and password for each application. It is fully integrated with Oracle Internet Directory, which stores user information. It supports LDAP-based user and password management through Oracle Internet Directory.

mod_osso, an Oracle HTTP Server module, enables the transparent use of Oracle Application Server Single Sign-On across all of Oracle Application Server. Through mod_osso, Oracle HTTP Server becomes a SSO partner application enabled to use SSO to authenticate users and obtain their identity, and to make user identities available to Web applications as an Apache header variable.


See Also:

"Using mod_osso to Authenticate Users" for detailed information regarding mod_osso.

  Previous Next
Oracle Logo
Copyright © 2002, 2004, Oracle. All rights reserved.
  Go To Documentation Library
Home		 Go To Product List
Solution Area		 Go To Table Of Contents
Contents		 Go To Index
Index