|
Oracle® HTTP Server Administrator's Guide
10g Release 2 (10.1.2) B14007-03 |
|
 Previous |
 Next |
|
Oracle® HTTP Server Administrator's Guide
10g Release 2 (10.1.2) B14007-03 |
|
|
Previous |
Next |
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:
|
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
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:
Users that access the server without providing any authentication. They have access to unprotected resources only.
Users that have been authenticated and potentially authorized by modules within Oracle HTTP Server. This includes users authenticated by mod_auth and mod_ossl. Such users have access to URLs defined in http.conf file.
Users that have been authenticated through mod_osso and Single Sign-On server. These users have access to resources allowed by Single Sign-On.
Oracle HTTP Server is configured to protect resources such as:
Static content such as static HTML pages, graphics interchange format, .gif, files, and other static files that Oracle HTTP Server provides directly.
CGI/FastCGI scripts, simple scripts or programs that Oracle HTTP Server invokes directly.
Content generated by modules within Oracle HTTP Server. Modules such as mod_perl, mod_dms generate responses that are returned to the client.
Oracle Application Server components that exist behind Oracle HTTP Server, including servlets and JSPs running with OC4J that are accessed through mod_oc4j. Oracle HTTP Server forms the first line of authentication and authorization for these components, although further authentication may occur at the component level.
Oracle HTTP Server provides user authentication and authorization at two stages:
Host-based Access Control (stage one): This is based on the details of the incoming HTTP request and its headers, such as IP addresses or host names.
User Authentication and Authorization (stage two): This is 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.
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:
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. |
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:
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 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.
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.
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.
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.
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>
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.
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 |
|---|---|
|
Defines the name of the realm in which the user names and passwords are valid. Use quotation marks if the name includes spaces. |
|
|
Specifies the authentication type. Most authentication modules use basic authentication, which transmits user names and passwords in clear text. This is not recommended. |
|
|
|
Specifies the path to a file that contains user names and passwords. |
|
Specifies the path to a file that contains group names and their members. |
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.
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. 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 shows an Oracle Application Server configuration using port tunneling. The iaspt daemon, a standalone 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 supports application partitioning. Oracle HTTP Server also supports automatic failover of requests which cannot be sent to a given iaspt daemon.
Perform the following three tasks to configure port tunneling:
Perform the following steps to start one or more iaspt daemons:
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".
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>
Run the following command to direct the opmn daemon to reload its configuration file:
opmnctl reload
Perform the following steps to configure iaspt.conf to specify an SSL wallet for the iaspt daemon(s) to use:
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>
Start the iaspt daemon(s) using the following command:
opmnctl startall
Perform the following steps to configure mod_oc4j.conf to route requests using iaspt:
Enable port tunneling by adding the following line in mod_oc4j.conf:
Oc4jiASPTActive on
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.
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
Restart Oracle HTTP Server for the changes to take effect, using the following command:
UNIX: ORACLE_HOME/opmn/bin> opmnctl [verbose] restartproc ias-component=HTTP_Server
Windows: ORACLE_HOME\opmn\bin> opmnctl [verbose] restartproc ias-component=HTTP_Server
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:
In iaspt.conf, change the value "destination-ssl" from "false" to "true".
To configure the OC4J process to use SSL, refer to the Oracle Application Server Containers for J2EE Security Guide.
This section contains information about the following configuration files and their parameters:
Describes the process that OPMN manages within an Oracle Application Server installation.
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.
An out of the box Oracle Application Server installation contains an iaspt component in opmn.xml, but it is disabled by default.
Configures mod_oc4j with Oracle HTTP Server.
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.
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: |
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: |
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 |
Configures port tunneling.
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: |
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 |
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: |
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 |
This section discusses how Oracle HTTP Server uses the Oracle Identity Management Infrastructure.
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.
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, 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.
