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:
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.
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
Users who have been authenticated through Oracle Access Manager. These users have access to resources allowed by Single Sign-On.
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.
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.
The Apache HTTP Server authentication directives can be used to verify that users are who they claim to be.
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.
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
Use the Audit Policies page in Fusion Middleware Control to assign audit policies to a selected Oracle HTTP Server instance.
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
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.
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.
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 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.
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:
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
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).
httpd.confconfiguration file with the external name of the server and its port number, for example:
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
AddModule line should be included with other
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
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.
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_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>
/index.htmland then your test your application.
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
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
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.
mod_wl_ohs.conffile to add the
WLSProxySSLdirective for the location of your non-SSL configured managed servers.
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.
SecureProxydirective is not configured, as it will interfere with the intended communication between the components.
SecureProxydirective is commented out in the following example:
# To configure SSL throughout (all the way to WLS): # SecureProxy ON # WLSSLWallet "<Path to Wallet>"
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.
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.