4
Configuring HTTP Server Security

As described in the introductory chapter of this document, security can be organized into the three categories of authentication, authorization, and encryption. 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 module, mod_auth, and the Oracle modules, mod_ossl and mod_osso. The module mod_auth provides authentication based on user name and password pairs, mod_ossl provides confidentiality and authentication with X.509 client certificates over SSL, and mod_osso enables single sign-on for Web applications.

This chapter provides an overview of Oracle HTTP Server security features and configuration information for setting up a secure Web site using them. It contains these topics:

• Overview of Oracle HTTP Server Security

• Understanding Host-Based Access Control

• Overview of User Authentication

• Using Basic Authentication and Authorization with mod_auth

• Using Secure Sockets Layer (SSL) to Authenticate Users

• Using the iasobf Utility to Encrypt Wallet Passwords

  See Also: Chapter 3, "Configuring Oracle9iAS Single Sign-On" for information about configuring the Oracle module, mod_osso, that enables single sign-on for Web applications.

Overview of Oracle HTTP Server Security

Based on the Apache model, Oracle HTTP Server provides access control, authentication, and authorization methods that can be configured with access control directives that are used in the httpd.conf file. When URL requests arrive at Oracle HTTP Server, they are processed in a number of steps determined by the default design of the server and by what configuration parameters you set in the configuration files. The steps for handling URL requests are implemented through a module or plug-in architecture that is common to many Web listeners. Figure 4-1 shows how URL requests are handled by the server. Each step in this process is handled by a different server module depending on how the server is configured. For example, if only basic authentication is used, then the step labeled "Authentication" in Figure 4-1 represents the module, mod_auth.

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

Text description of the illustration ohsurlpr.gif

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

• First stage (host-based access control): based on the details of the incoming HTTP request and its headers, such as IP addresses or host names.

• Second stage (user authentication): based on different criteria depending on the HTTP server configuration. The server can be configured to authenticate users with user name and password pairs that are checked against a list of known users and passwords. You can also configure the server to use single sign-on authentication for Web applications or X.509 client certificates over SSL.

Specifying Configuration Parameters in httpd.conf

Parameters for all Oracle HTTP Server configuration directives that are described in this chapter must be entered in the main HTTP server configuration file called httpd.conf, which is located in the following directory:

• (UNIX) ORACLE_HOME/Apache/Apache/conf/httpd.conf

• (Windows) ORACLE_HOME\Apache\Apache\conf\httpd.conf

  See Also: (All of the following documents are located in the Oracle9iAS Documentation Library unless otherwise specified.) Oracle HTTP Server Administration Guide for information about all of the modules that Oracle Corporation supports. Oracle9i Application Server Administrator's Guide for information about specifying configuration parameters in the httpd.conf file in the Oracle HTTP Server home page of the Oracle9i Application Server Administration Service. Use this means of setting the configuration parameters for a clustered environment.

The following sections explain how host-based access control and user authentication is handled in the HTTP server and how to configure them.

Understanding 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> configuration directives as shown in the sample below:

<Directory /internalonly/>

order deny, allow
deny from all
allow from 192.168.1 us.oracle.com

</Directory>

In this example, requests originating from any IP address in the 192.168.1.* range or with the host name us.oracle.com are allowed access to files in the directory /internalonly/.

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>. However, if you want to direct proxy control, then you must use <Directory>.

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. The following example shows an excerpt from an httpd.conf file which provides the syntax for using AccessConfig this way:

...
<VirtualHost ip.address.of.host.some_domain.com>

... virtual host directives ...
AccessConfig conf/access.conf

</VirtualHost>

Overview of Host-Based Access Control Schemes

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. When you enter configuration directives into the httpd.conf 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, CGI applications, or components.

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

• Controlling Access by IP Address

• Controlling Access by Domain Name

• Controlling Access by Network or Netmask

• Controlling Access with Environment Variables

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. However, if IP addresses change without warning, your server is left unprotected.

To configure IP address-based access control, use the syntax shown in the following example:

<Directory /secure_only/>
     order deny,allow
     deny from all
     allow from 207.175.42.154 192.220.208.9
</Directory>

In this example, requests originating from all IP addresses except 207.175.42.154 and 192.220.208.9 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 the following example:

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

In this example 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.179. Although this is not a foolproof 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 the following example:

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

In this example, 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 the example above, 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. Two directives, BrowserMatch and SetEnvIf, can be used for this type of access control.

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

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 example, if you want to deny access from any browsers using HTTP version 1.0 or earlier, then use the syntax shown in the following example:

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>

Overview of User Authentication

User authentication is a term for a process used to ensure that users are who they claim to be. Basic authentication uses a user name and password. SSL uses an exchange of keys and client certificates. Oracle9iAS Single Sign-On initially uses a user name and password that are stored on Oracle Internet Directory, but after initial authentication, it places a cookie in the user's browser. During subsequent user logins to applications that are registered to use single sign-on, the browser cookie authenticates users transparently until the cookie expires.

The type of user authentication that you choose to use depends on the type of content you want to protect. Typically, basic authentication that is based on user name and password pairs is adequate for static content that only requires minimal security within an intranet. For Internet communications, SSL, which encrypts data and supports X.509 client certificates, is usually used for transmitting sensitive information such as passwords and authenticating users to Web applications and databases. To provide additional security and convenience, Oracle HTTP Server also supports single sign-on, which allows users to log in to multiple Web applications using a single user name and password.

The following sections describe how to use basic authentication and SSL with Oracle HTTP Server:

• Using Basic Authentication and Authorization with mod_auth

• Using Secure Sockets Layer (SSL) to Authenticate Users

  See Also: Chapter 3, "Configuring Oracle9iAS Single Sign-On" for information about how single sign-on works and how to register Oracle HTTP Server to use the Oracle module mod_osso that supports communication with the Oracle9iAS Single Sign-On server.

Using Basic Authentication and Authorization with mod_auth

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.

Frequently, basic user authentication and authorization are implemented together. User authentication, the second stage of security provided by Oracle HTTP Server, 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. For example, mod_auth uses the AuthUserFile directive to set up basic authentication.

What Directives to Use for Basic Authentication Configuration with mod_auth

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

Table 4-1 Authentication Configuration Directives  

User Authorization

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 Secure Sockets Layer (SSL) to Authenticate Users

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.

SSL provides secure communication between client and server by allowing mutual authentication, the use of digital certificates for integrity, and encryption for confidentiality. The protocol is designed to support a range of choices for specific algorithms used for cryptography, message digests, and certificates. This allows algorithm selection for specific servers to be made based on legal, export, or other concerns, and also enables the protocol to take advantage of new algorithms. Choices are negotiated between client and server at the start of establishing a protocol session.

About Securing HTTP Communication with mod_ossl

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 443.

mod_ossl is the Oracle Secure Sockets Layer (SSL) implementation in use with the Oracle database. mod_ossl replaces mod_ssl in the Oracle HTTP Server distribution. Oracle no longer supports mod_ssl. A tool is provided to enable you to migrate from mod_ssl to mod_ossl, and convert your text certificates to Oracle wallets.

mod_ossl 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.

• Authorization of clients with multiple access checks, exactly as performed in mod_ssl.

Table 4-2 identifies the differences between the Oracle module, mod_ossl, and mod_ssl.

Table 4-2 Differences between mod_ossl and mod_ssl  

The mod_ssl directives listed below are not supported by mod_ossl.

• SSLRandomSeed

• SSLCertificateFile

• SSLCertificateKeyFile

• SSLCertificateChainFile

• SSLCACertificateFile

• SSLCACertificatePath

• SSLVerifyDepth

  Caution: The server will not start if these directives are used.

  See Also: Chapter 5 for information about Oracle Wallet Manager and how to use it to request, store, and manage certificates.

Understanding Classes of Directives Used for Configuring SSL

Directives are classified according to the context in which they can be used: global, per-server, and per-directory.

Table 4-3 Classes and Directives  

Note that each class is a subset of the class above it. For example, directives from the per-directory class can also be used in the per-server and global contexts, and directives from the per-server class can be used in the global context.

Using mod_ossl Directives

To configure SSL for your HTTP server, you enter the mod_ossl directives you want to use in the httpd.conf file. Each directive is described below.

SSLWallet

SSLWallet file:/etc/ORACLE/WALLETS/server

SSLWalletPassword

SSLPassPhraseDialog

SSLPassPhraseDialog exec:/usr/local/apache/sbin/pfilter

SSLCARevocationPath

SSLCARevocationPath /ias2/Apache/conf/ssl.crl/

SSLCARevocationFile

SSLCARevocationFile /ias2/Apache/conf/ssl.crl/ca_bundle.crl

SSLMutex

SSLMutex file:/usr/local/apache/logs/ssl_mutex

SSLSessionCache

SSLSessionCache shmht:/iasv2/Apache/Apache/logs/ssl_scache(512000)
SSLSessionCache shmcb:/iasv2/Apache/Apache/logs/ssl_scache(512000)

SSLSessionCacheTimeout

SSLProtocol

SSLCipherSuite

Table 4-4 SSLCipher Suite Tags  

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

SSLVerifyClient

SSLLog

SSLLogLevel

SSLOptions

SSLRequireSSL

SSLRequire

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}"

function ::= funcname "(" funcargs ")"

file(filename)

Table 4-6 Standard variables for SSLRequire varname

Table 4-7 SSL variables for SSLRequire varname  

Using the iasobf Utility to Encrypt Wallet Passwords

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 Corporation recommends that you use the password obfuscation tool iasobf, which is located in the HTTP server bin directory 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.