Skip Headers
Oracle® HTTP Server Administering a Standalone Deployment Based on Apache 1.3
10g Release 2 (10.1.2)
B14008-02
  Go To Documentation Library
Home
Go To Product List
Solution Area
Go To Table Of Contents
Contents
Go To Index
Index

Previous
Previous
Next
Next
 

9 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:


See Also:

For additional information about security, refer to the following documents:

9.1 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 9-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 9-1 represent the processing of the mod_auth module.

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

Description of Figure 9-1  follows
Description of "Figure 9-1 Steps for Handling URL Requests in Oracle HTTP Server"

9.2 Classes of Users and Their Privileges

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

9.3 Resources Protected

Oracle HTTP Server is configured to protect resources such as:

9.4 Authentication and Authorization Enforcement

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

9.4.1 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 9-1:

Example 9-1 Host-based Access Control

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

In Example 9-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.

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

Example 9-2 Using AccessConfig to Set Up Access Control

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

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

9.4.1.2.1 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 9-3 Controlling Access by IP Address

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

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

9.4.1.2.2 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 9-4:

Example 9-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 9-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.

9.4.1.2.3 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 9-5:

Example 9-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 9-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 9-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.

9.4.1.2.4 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 9-6:

Example 9-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 9-7:

Example 9-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>

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

9.4.2.1 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 9-1.

Table 9-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.


9.4.2.2 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 OracleAS 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.

9.4.2.3 Using mod_ossl to Authenticate Users

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:

"Enabling SSL for Oracle HTTP Server" for information on enabling and configuring SSL using mod_ossl directives.

9.5 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 many ports to handle communication between Oracle HTTP Server and multiple OC4J instances.


See Also:

Oracle HTTP Server Administrator's Guide for a detailed description of port tunneling.

9.5.1 Configuring Port Tunneling

Perform the following three tasks to configure port tunneling:

9.5.1.1 Task 1: Configure opmn.xml

Perform the following steps on the middle-tier install (and not the standalone Oracle HTTP Server 1.3 installation) to start one or more iaspt daemons:

  1. By default, there is an opmn.xml entry for iaspt that is disabled. Enable iaspt by editing opmn.xml and changing status="disable" to status="enable".

  2. Optionally, you may also change the TCP/IP ports used by the iaspt daemon by changing the port "range" and the number of the iaspt daemon processes by changing "numprocs".

    The following 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> 
    
    
  3. Run the following command to direct the opmn daemon to reload its configuration file:

    opmnctl reload
    
    

9.5.1.2 Task 2: Configure iaspt.conf

Perform the following steps on the middle-tier install (and not the standalone Oracle HTTP Server 1.3 installation) to configure iaspt.conf to specify an SSL wallet for the iaspt daemon(s) to use:

  1. Communication between mod_oc4j and iaspt is always encrypted, therefore an SSL wallet file must be configured for the iaspt daemon(s). By default, this wallet is the same as the Oracle HTTP Server wallet. You may change the default by editing the following values in iaspt.conf:

    wallet-file=<path to wallet file>
    wallet-password=<password>
    
    
  2. Start the iaspt daemon(s) using the following command:

    opmnctl startall
    
    

9.5.1.3 Task 3: Configure mod_oc4j.conf

Perform the following steps on the standalone Oracle HTTP Server 1.3 installation (and not the middle tier install) to configure mod_oc4j.conf to route requests using iaspt:

  1. Enable port tunneling by adding the following line in mod_oc4j.conf:

    Oc4jiASPTActive on
    
    
  2. Specify an SSL wallet and wallet password for mod_oc4j.conf by adding the following two lines in mod_oc4j.conf:

    Oc4jiASPTWalletFile <path to wallet file>
    Oc4jiASPTWalletPassword <password of wallet>
    
    

    This wallet may be the same as used by Oracle HTTP Server and/or iaspt.

  3. Specify the host and port addresses of the iaspt daemons. For example, add the following line to mod_oc4j.conf:

    Oc4jiASPTProcess myhost.us.oracle.com:6701
    
    

    You may add as many Oc4jiASPTProcess lines as you have iaspt daemons. The host and port addresses must match those of your configured iaspt daemons. For example, to route requests to the three iaspt daemons configured in the example in step 2 of "Task 1: Configure opmn.xml", add the following three lines:

    Oc4jiASPTProcess myhost.us.oracle.com:6701
    Oc4jiASPTProcess myhost.us.oracle.com:6702
    Oc4jiASPTProcess myhost.us.oracle.com:6703
    
  4. Restart Oracle HTTP Server for the changes to take effect, using the following command:

    opmnctl restartproc ias-component=HTTP_Server
    
    

9.5.2 Configuring SSL for Port Tunneling

This section contains information about configuring SSL between iaspt and OC4J

By default, the iaspt daemons and the OC4J processes communicate with unencrypted data. Perform the following steps to configure SSL communication between these processes:

  1. In iaspt.conf, change the value "destination-ssl" from "false" to "true".

  2. To configure the OC4J process to use SSL, refer to the Oracle Application Server Containers for J2EE Security Guide.

9.5.3 Port Tunneling Configuration Reference

This section contains information about the following configuration files and their parameters involved in the port tunneling process.

9.5.3.1 opmn.xml

Describes the process that OPMN manages within an Oracle Application Server installation.


See Also:

"opmn.xml"

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:

    iaspt.conf

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

9.5.3.2 mod_oc4j.conf

Configures mod_oc4j with Oracle HTTP Server.


See Also:

"mod_oc4j.conf"

For port tunneling, you need to add 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:

    iaspt.conf

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

The following directives used 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 instances of this directive within a mod_oc4j.conf file for multiple port tunneling processes.

The syntax for this directive is host:port. The host value should be the hostname of a machine where an iaspt daemon is running. The port value should match the port configured in opmn.xml for that iaspt. Both regular hostname and IP address are allowed for 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


mod_oc4j should use SSL when communicating with the iaspt daemon. The following are the directives used to enable SSL:

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 Password used for authentication when opening the wallet file specified by Oc4jiASPTWalletFile.
Default Value N/A


See Also:

Oracle Application Server Administrator's Guide for information on Oracle Wallet Manager.

9.5.3.3 iaspt.conf

Configures port tunneling.


See Also:

"iaspt.conf"

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.

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

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 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 Password used for authentication when opening the wallet file specified by wallet-file
Default Value N/A


See Also:

Oracle Application Server Administrator's 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

9.6 Leveraging Oracle Identity Management Infrastructure

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

9.6.1 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, OracleAS Single Sign-On, and Oracle Certificate Authority.

9.6.2 Using OracleAS Single Sign-On and mod_osso

Oracle Application Server supports single sign-on (SSO) to Web-based applications through OracleAS 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, 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 OracleAS 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.