9 Managing Application Security

Oracle HTTP Server supports three main categories of security, namely, authentication, authorization, and confidentiality.

To know more about Oracle HTTP Server security features and configuration information for setting up a secure website, see the following sections:

About Oracle HTTP Server Security

Oracle HTTP Server supports all three security categories, namely, authentication, authorization, and confidentiality. Oracle HTTP Server’s security infrastructure is primarily provided by Apache security modules.

Oracle HTTP Server is based on the Apache HTTP Server, and its security infrastructure is primarily provided by the Apache modules, mod_auth_basic, mod_authn_file, mod_auth_user, and mod_authz_groupfile, and WebGate. The mod_auth_basic, mod_authn_file, mod_auth_user, and mod_authz_groupfile modules provide authentication based on user name and password pairs, while mod_authz_host controls access to the server based on the characteristics of a request, such as host name or IP address, mod_ossl provides confidentiality and authentication with X.509 client certificates over SSL.

Oracle HTTP Server provides access control, authentication, and authorization methods that you can configure 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.

Classes of Users and Their Privileges

Oracle HTTP Server authorizes and authenticates users before allowing them to access or modify resources on the server, based on their user privileges.

.The following are three classes of users that access the server using Oracle HTTP Server, and their privileges:

Users who access the server without providing any authentication. They have access to unprotected resources only.
Users who have been authenticated and potentially authorized by modules within Oracle HTTP Server. This includes users authenticated by Apache HTTP Server modules like mod_auth_basic, mod_authn_file, mod_auth_user, and mod_authz_groupfile modules and Oracle's mod_ossl. Such users have access to URLs defined in http.conf file.

See Also:

Authentication, Authorization and Access Control.
Users who have been authenticated through Oracle Access Manager. These users have access to resources allowed by Single Sign-On.

See Also:

Securing Applications with Oracle Platform Security Services

Authentication, Authorization and Access Control

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

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. You can configure the server 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.

Access Control

Access control refers to any means of controlling access to any resource.

See Also:

Refer to the Apache HTTP Server documentation for more information on how to configure access control to resources.

User Authentication and Authorization

Authentication is any process by which you verify that someone is who they claim they are. Authorization is any process by which someone is allowed to be where they want to go, or to have information that they want to have. You can authenticate users with either Apache HTTP Server modules or with WebGate.

Authenticating Users with Apache HTTP Server Modules

The Apache HTTP Server authentication directives can be used to verify that users are who they claim to be.

See Also:

For more information on how to authenticate users, see the Apache HTTP Server documentation on "Authentication and Authorization" at:

http://httpd.apache.org/docs/2.4/howto/auth.html

Authenticating Users with WebGate

WebGate enables single sign-on (SSO) for Oracle HTTP Server. WebGate examines incoming requests and determines whether the requested resource is protected, and if so, retrieves the session information for the user.

Through WebGate, Oracle HTTP Server becomes an SSO partner application enabled to use SSO to authenticate users, obtain their identity by using Oracle Single Sign-On, and to make user identities available to web applications accessed through Oracle HTTP Server.

By using WebGate, web applications can register URLs that require SSO authentication. WebGate detects which requests received by Oracle HTTP Server require SSO authentication, and redirects them to the SSO server. Once the SSO server authenticates the user, it passes the user's authenticated identity back to WebGate in a secure token. WebGate retrieves the user's identity from the token and propagates it to applications accessed through Oracle HTTP Server, including applications running in Oracle WebLogic Server and CGIs and static files handled by Oracle HTTP Server.

Support for FMW Audit Framework

Oracle HTTP Server supports authentication and authorization auditing by using the FMW Common Audit Framework. As part of enabling auditing, Oracle HTTP Server supports a directive called OraAuditEnable, which defaults to On. When it is enabled, audit events enabled in auditconfig.xml will be recorded in an audit log. By default, no audit events are enabled in auditconfig.xml.

When OraAuditEnable is set to Off, auditing is disabled regardless of the settings in auditconfig.xml.

You can configure audit filters using Fusion Middleware Control or by editing auditconfig.xml directly.

See Also:

Overview of Audit Features in Securing Applications with Oracle Platform Security Services

Managing Audit Policies Using Fusion Middleware Control

Use the Audit Policies page in Fusion Middleware Control to assign audit policies to a selected Oracle HTTP Server instance.

Navigate to the Oracle HTTP Server Home Page.
Select the server instance to which you want to apply audit policies.
From the Oracle HTTP Server drop-down menu, select Security, then Audit Policy.

The Audit Policy page opens.

For more information on setting audit policies, see Managing Audit Policies for Java Components with Fusion Middleware Control in Securing Applications with Oracle Platform Security Services

Implementing SSL

Oracle HTTP Server secures communications by using a Secure Sockets Layer (SSL) protocol. SSL secures communication by providing message encryption, integrity, and authentication. The SSL standard allows the involved components (such as browsers and HTTP servers) to negotiate which encryption, authentication, and integrity mechanisms to use.

For details on how to implement SSL for Oracle HTTP Server, see Configuring SSL for the Web Tier in Administering Oracle Fusion Middleware. For information on using mod_ossl, Oracle's SSL module, see mod_ossl Module—Enables Cryptography (SSL). For information about mod_ossl directives, see mod_ossl Module.

The mod_wl_ohs module also contains a configuration for SSL. See Using SSL with Plug-ins and Parameters for Web Server Plug-Ins in Using Oracle WebLogic Server Proxy Plug-Ins.

These sections describes SSL features that are supported for this release.

Global Server ID Support

This feature adds support SSL protocol features called variously "step-up", "server gated crypto" or "global server ID". "Step-up" is a feature that allows old, weak encryption browsers, to "step-up" so that public keys greater than 512-bits and bulk encryption keys greater than 64 bits can be used in the SSL protocol. This means that server X.509 certificates that contain public keys in excess of 512-bits and which contain "step-up" digital rights can now be used by Oracle Application Server. Such certificates are often called "128-bit" certificates, even though the certificate itself typically contains a 1024-bit certificate. The Verisign Secure Site Pro is an example of such a certificate which can now be used by Oracle Application Server.

Global Server ID functionality is provided by default, there is no configuration necessary.

PKCS #11 Support

Public-Key Cryptography Standards #11, or PKCS #11 for short, is a public key cryptography specification that outlines how systems use hardware security modules, which are basically "boxes" where cryptographic functions (encryption/decryption) are performed and where encryption keys are stored.

Oracle HTTP Server supports the option of having dedicated SSL hardware through nCipher. nCipher is a certified third-party accelerator that improves the performance of the PKI cryptography that SSL uses.

See Also:

SSL and Logging

SSL- and communication-related debugging can be set using the SSLTraceLogLevel directive. Here you can set different verbosity of log level according to your logging requirements. This directive generates SSL and communication logs. See SSLTraceLogLevel Directive.

Note:

SSL logs will work when Oracle HTTP Server logs is set for INFO or higher level.

Terminating SSL Requests

The following sections describe how to terminate requests using SSL before or within Oracle HTTP Server, where the mod_wl_ohs module forwards requests to WebLogic Server. Whether you terminate SSL before the request reaches Oracle HTTP Server or when the request is in the server, depends on your topology. A common reason to terminate SSL is for performance considerations when an internal network is otherwise protected with no risk of a third-party intercepting data within the communication. Another reason is when WebLogic Server is not configured to accept HTTPS requests.

This section includes the following topics:

About Terminating SSL at the Load Balancer

If you are using another device such as a load balancer or a reverse proxy which terminates requests using SSL before reaching Oracle HTTP Server, then you must configure the server to treat the requests as if they were received through HTTPS. The server must also be configured to send HTTPS responses back to the client.

Figure 9-1 illustrates an example where the request transmitted from the browser through HTTPS to WebLogic Server. The load balancer terminates SSL and transmits the request as HTTP. Oracle HTTP Server must be configured to treat the request as if it was received through HTTPS.

Figure 9-1 Terminating SSL Before Oracle HTTP Server

Description of "Figure 9-1 Terminating SSL Before Oracle HTTP Server"

Terminating SSL at the Load Balancer

To instruct the Oracle HTTP Server to treat requests as if they were received through HTTPS, configure the httpd.conf file with the SimulateHttps directive in the mod_certheaders module.

For more information on mod_certheaders module, see mod_certheaders Module—Enables Reverse Proxies.

Note:

This procedure is not necessary if SSL is configured on Oracle HTTP Server (that is, if you are directly accessing Oracle HTTP Server using HTTPS).

Configure the httpd.conf configuration file with the external name of the server and its port number, for example:
```
ServerName <www.company.com:port>
```
Configure the httpd.conf configuration file to load the mod_certheaders module, for example:
- On UNIX:
```
LoadModule certheaders_module libexec/mod_certheaders.so
```
- On Windows:
```
LoadModule certheaders_module modules/ApacheModuleCertHeaders.dll
AddModule mod_certheaders.c
```
  Note:
  
  Oracle recommends that the AddModule line should be included with other AddModule directives.
Configure the SimulateHttps directive at the bottom of the httpd.conf file to send HTTPS responses back to the client, for example:
```
# For use with other load balancers and front-end devices:
SimulateHttps On
```
Restart Oracle HTTP Server and test access to the server. Especially, test whether you can access static pages such as https://host:port/index.html

Test your configuration as a basic setup. If you are having issues, then you should troubleshoot from here to avoid overlapping with other potential issues, such as with virtual hosting.
Ideally, you may want to configure a VirtualHost in the httpd.conf file to handle all HTTPS requests. This separates the HTTPS requests from the HTTP requests as a more scalable approach. This may be more desirable in a multi-purpose site or if a load balancer or other device is in front of Oracle HTTP Server which is also handling both HTTP and HTTPS requests.
The following sample instructions load the mod_certheaders module, then creates a virtual host to handle only HTTPS requests.
```
# Load correct module here or where other LoadModule lines exist:
LoadModule certheaders_module libexec/mod_certheaders.so
# This only handles https requests:
   <VirtualHost <name>:<port>
       # Use name and port used in url:
       ServerName <www.company.com:port>
       SimulateHttps On
       # The rest of your desired configuration for this VirtualHost goes here
   </VirtualHost>
```
Restart Oracle HTTP Server and test access to the server, First test a static page such as https://host:port/index.html and then your test your application.

About Terminating SSL at Oracle HTTP Server

If SSL is configured in Oracle HTTP Server but not on Oracle WebLogic Server, then you can terminate SSL for requests sent by Oracle HTTP Server.

The following figures illustrate request flows, showing where HTTPS stops. In Figure 9-2, an HTTPS request is sent from the browser. The load balancer transmits the HTTPS request to Oracle HTTP Server. SSL is terminated in Oracle HTTP Server and the HTTP request is sent to WebLogic Server.

Figure 9-2 Terminating SSL at Oracle HTTP Server—With Load Balancer

Description of "Figure 9-2 Terminating SSL at Oracle HTTP Server—With Load Balancer"

In Figure 9-3 there is no load balancer and the HTTPS request is sent directly to Oracle HTTP Server. Again, SSL is terminated in Oracle HTTP Server and the HTTP request is sent to WebLogic Server.

Figure 9-3 Terminating SSL at Oracle HTTP Server—Without Load Balancer

Description of "Figure 9-3 Terminating SSL at Oracle HTTP Server—Without Load Balancer"

Terminating SSL at Oracle HTTP Server

To instruct the Oracle HTTP Server to treat requests as if they were received through HTTPS, configure the WLSProxySSL directive in the mod_wl_ohs.conf file and ensure that the SecureProxy directive is not configured.

Configure the mod_wl_ohs.conf file to add the WLSProxySSL directive for the location of your non-SSL configured managed servers.
For example:
```
WLProxySSL ON
```
If using a load balancer or other device in front of Oracle HTTP Server (which is also using SSL), you might need to configure the WLProxySSLPassThrough directive instead, depending on if it already sets WL-Proxy-SSL.
For example:
```
WLProxySSLPassThrough ON
```
For more information, see your load balancer documentation. For more information on WLProxySSLPassThrough, see Parameters for Oracle WebLogic Server Proxy Plug-Ins in Using Oracle WebLogic Server Proxy Plug-Ins.
Ensure that the SecureProxy directive is not configured, as it will interfere with the intended communication between the components.
This directive is to be used only when SSL is used throughout. The SecureProxy directive is commented out in the following example:
```
# To configure SSL throughout (all the way to WLS):
# SecureProxy ON
# WLSSLWallet  "<Path to Wallet>" 
```
Enable the WebLogic Plug-In flag for your managed servers or cluster.
By default, this option is not enabled. Complete the following steps to enable the WebLogic Plug-In flag:
1. Log in to the Oracle WebLogic Server Administration Console.
2. In the Domain Structure pane, expand the Environment node.
3. Click on Clusters.
4. Select the cluster to which you want to proxy requests from Oracle HTTP Server.
  The Configuration: General tab appears.
5. Scroll down to the Advanced section, expand it.
6. Click Lock and Edit.
7. Set the WebLogic Plug-In Enabled to yes.
8. Click Save and Activate the Changes.
9. Restart the servers for the changes to be effective.
Restart Oracle HTTP Server and test access to a Java application.
For example: https://host:port/path/application_name.

Using mod_security

mod_security is an open-source module that you can use to detect and prevent intrusion attacks against Oracle HTTP Server.

An example of how you can use mod_security to prevent intrusion is by specifying a mod_security rule to screen all incoming requests and deny requests that match the conditions specified in the rule. The mod_security module (version 2.7.2) and its prerequisites are included in the Oracle HTTP Server installation as a shared object named mod_security2.so in the ORACLE_HOME/ohs/modules directory.

See Configuring the mod_security Module.

Using Trust Flags

Trust flags allow adequate roles to be assigned to certificates to facilitate operations like certificate chain validation and path building. However, by default, wallets do not support trust flags.

You can use the orapki utility to maintain trust flags in the certificates installed in an Oracle Wallet. You can create and convert wallets to support trust flags, create and maintain appropriate flags in each certificate, and so on. For more information on trust flags and instructions on how to incorporate them into your security strategy, see Creating and Managing Trust Flags in Administering Oracle Fusion Middleware.