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. These users have access to URLs defined in
http.conffile. See 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 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 refers to any means of controlling access to any resource.
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.
For more information about how to authenticate users, see Apache HTTP Server documentation.
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.
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.
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, and then select Audit Policy.
The Audit Policy page appears.
For more information about setting audit policies, see Managing Audit Policies for Java Components with Fusion Middleware Control in Securing Applications with Oracle Platform Security Services.
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.
These sections describes SSL features that are supported for this release.
Global Server ID Support
The global ID support feature adds support SSL protocol features called variously as 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.
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 is a certified third-party accelerator that improves the performance of the PKI cryptography that SSL uses.
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.
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 10-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 10-1 Terminating SSL Before Oracle HTTP Server
Description of "Figure 10-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
For more information on
mod_certheaders module, see mod_certheaders Module—Enables Reverse Proxies.
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.confconfiguration file with the external name of the server and its port number, for example:
- Configure the
httpd.confconfiguration file to load the
mod_certheadersmodule, for example:
LoadModule certheaders_module libexec/mod_certheaders.so
LoadModule certheaders_module modules/ApacheModuleCertHeaders.dll AddModule mod_certheaders.c
Oracle recommends that the
AddModuleline should be included with other
- Configure the
SimulateHttpsdirective at the bottom of the
httpd.conffile 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
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
httpd.conffile 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_certheadersmodule, 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.example.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
/index.htmland 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 10-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 10-2 Terminating SSL at Oracle HTTP Server—With Load Balancer
Description of "Figure 10-2 Terminating SSL at Oracle HTTP Server—With Load Balancer"
In Figure 10-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 10-3 Terminating SSL at Oracle HTTP Server—Without Load Balancer
Description of "Figure 10-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
.conf file and ensure that the
SecureProxy directive is not configured.
- Configure the
mod_wl_ohs.conffile to add the
WLSProxySSLdirective for the location of your non-SSL configured managed servers.For example:
- 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
WLProxySSLPassThroughdirective instead, depending on if it already sets
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
SecureProxydirective 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
SecureProxydirective 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:
- Log in to the Oracle WebLogic Server Administration Console.
- In the Domain Structure pane, expand the Environment node.
- Click on Clusters.
- Select the cluster to which you want to proxy requests from Oracle HTTP Server. The Configuration: General tab appears.
- Scroll down to the Advanced section, expand it.
- Click Lock and Edit.
- Set the WebLogic Plug-In Enabled to yes.
- Click Save and Activate the Changes.
- Restart the servers for the changes to be effective.
- Restart Oracle HTTP Server and test access to a Java application. For example:
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.
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.
Enabling Perfect Forward Secrecy on Oracle HTTP Server
Perfect Forward Secrecy (PFS) is a feature of specific key agreement protocols that gives assurance that your session keys will not be compromised even if the private key of the server is compromised.
In Apache, the
SSLHonorCipherOrder directive is used. This directive is supported in Oracle HTTP Server 12.2.1 and later.
Oracle HTTP Server out of the box configuration does not explicitly enable Perfect Forward Secrecy feature. To enable PFS, do the following configuration changes in the Oracle HTTP Server:
- Configure TLS1.2 protocol for OHS server using SSLProtocol directive. See SSLProtocol Directive.
- Enforce the ordering of server cipher suites by setting SSLHonorCipherOrder to
ON. See SSLHonorCipherOrder Directive.
- Use ECC certificates in Oracle HTTP Server wallet. See Adding an ECC Certificate to Oracle Wallets with orapki in Administering Oracle Fusion Middleware.
- Configure ECDHE_ECDSA Cipher Suites in OHS. For the list of supported ECDHE_ECDSA cipher suites, see SSLCipherSuite Directive.