This chapter contains an overview of Oracle HTTP Server security features, and provides configuration information for setting up a secure Web site.
Note:Unless otherwise mentioned, the information in this document is applicable when Oracle HTTP Server is installed with Oracle WebLogic Server and Oracle Fusion Middleware Control. It is assumed that readers are familiar with the key concepts of Oracle Fusion Middleware, as described in the Oracle Fusion Middleware Concepts Guide and the Oracle Fusion Middleware Administrator's Guide.
For information about installing Oracle HTTP Server in standalone mode, see ”Installing Oracle Web Tier Without Oracle WebLogic Server” in the Oracle Fusion Middleware Installation Guide for Oracle Web Tier.
This chapter includes the following sections:
Security can be organized into the 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_basic, mod_authn_file, mod_auth_user, and mod_authz_groupfile, and the Oracle modules, mod_ossl and mod_osso. 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, and mod_osso enables single sign-on authentication for Web applications.
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 8-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 8-1 represent the processing of the Apache mod_auth_basic, mod_authn_file, mod_auth_user, and mod_authz_groupfile modules.
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 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 that have been authenticated through mod_osso and Single Sign-On server. These users have access to resources allowed by Single Sign-On.
See Also:Oracle Fusion Middleware Security Guide
Oracle HTTP Server may be configured since these resources are not protected out of the box:
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.
Oracle Application Server components that exist behind Oracle HTTP Server, including servlets and JSPs running with Oracle WebLogic Server that are accessed through mod_wl_ohs. Oracle HTTP Server forms the first line of authentication and authorization for these components, although further authentication may occur at the component level.
This section describes how to terminate SSL before or within Oracle HTTP Server, where the
mod_wl_ohs module is used to forward 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.
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 8-2 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.
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 Section E.1, "mod_certheaders."
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).
httpd.conf configuration file with the external name of the server and its port number, for example:
httpd.conf configuration file to load the
mod_certheaders module, for example:
LoadModule certheaders_module libexec/mod_certheaders.so
LoadModule certheaders_module modules/ApacheModuleCertHeaders.dll AddModule mod_certheaders.c
Note:Oracle recommends that the
AddModuleline should be included with other
AddCertHeader directives 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 # For use with Oracle Web Cache: AddCertHeader HTTPS
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
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: NameVirtualHost <name>:<port> <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
/index.html and then your test your application.
If SSL is configured in Oracle HTTP Server but not on 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 8-3, 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.
In Figure 8-4, 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.
mod_wl_ohs.conf file to add the
WLSProxySSL directive 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
WLProxySSLPassThrough directive instead, depending on if it already sets
WL-Proxy-SSL, for example:
For more information, see your load balancer documentation. For more information on WLProxySSLPassThrough, see "Parameters for Web Server Plug-Ins" in Using Web Server 1.1 Plug-Ins with Oracle WebLogic Server.
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>"
Restart Oracle HTTP Server and test access to a Java application, for example:
Oracle HTTP Server provides user authentication and authorization at two stages:
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.
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.
Critical Note:The FMW 10g-based Single Sign-On Plug-In, OSSO Plug-In for Oracle HTTP Server and other web servers. such as IIS, has been deprecated and will be discontinued in future releases.
You should migrate to the FMW 11g-based Oracle Access Manager WebGate for single sign-on functionality. Note that Oracle Access Manager and WebGate must be installed separately. For more information, see Fusion Middleware Administrator's Guide for Oracle Access Management at:
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.
The Apache HTTP Server authentication directives can be used to verify that users are who they claim to be.
See Also:Refer to the Apache HTTP Server documentation for more information on how to authenticate users.
Note:mod_osso for use with Oracle Single Sign-On 10g is deprecated and is not recommended for use. Instead, you should use the Oracle Access Manager.
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 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 Oracle WebLogic Server, and it can also authenticate users for access to static files.
See Also:Oracle Fusion Middleware Security Guide
Oracle HTTP Server supports a directive called
OraAuditEnable. The purpose of this directive is to enable auditing of authentication and authorization using the FMW Common Audit Framework. This directive takes on two values, ON and OFF. When the value is set to ON, all the audit events reported by Oracle HTTP Server are recorded into an audit framework specific file. By default, the value is ON. If
OraAuditEnable is set to OFF or is not present, then audit is disabled. The default
httpd.conf file that is provided with Oracle HTTP Server sets it to ON. For more information, see
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 Oracle Fusion Middleware Administrator's Guide. For information on using mod_ossl, Oracle's SSL module, see Section 3.6, "mod_ossl." For information on the directives available under mod_ossl, see Section E.4, "mod_ossl." .
The current release of Oracle HTTP Server and Oracle Web Cache adds support for the TLS v1.1 and TSL v1.2 security protocols and the following ciphers. For the complete list of security protocols and ciphers supported by the current release of Oracle HTTP Server, see Section E.4.12, "SSLProtocol" and Section E.4.4, "SSLCipherSuite."
In the current release, you cannot configure the security protocols TLSv1.1 or TLSv1.2 and their corresponding ciphers though Fusion Middleware Control. To implement these protocols and ciphers for your applications, you must manually edit the
ssl.conf file (
The following example configures the TLS v1.1 and TLS v1.2 protocols and three ciphers in the
... # SSL Protocol Support: # Configure usable SSL/TLS protocol versions. SSLProtocol +TLSv1.1 +TLSv1.2 # SSL Cipher Suite: # List the ciphers that the client is permitted to negotiate. SSLCipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA:TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384:TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ...
Because of security concerns, the SSLv3 security protocol is disabled out-of-the-box in the Oracle HTTP Server 22.214.171.124 release. The SSLv2 protocol is no longer supported by Oracle HTTP Server.
If you are upgrading from an earlier release of Oracle HTTP Server, the SSLv3 and/or SSLv2 security protocol might be a part of your configuration. Oracle strongly recommends that you disable any SSLv3 or SSLv2 configuration from Oracle HTTP Server.
To disable SSL security protocols from Oracle HTTP Server:
Examine your .
conf files (such as s
admin.conf, and any custom
.conf files) to look for security declarations such as
You can find the
admin.conf files in the following location:
Edit the security declaration to use a non-SSL protocol.
For example, to explicitly configure all of the currently supported security protocols, enter the following:
SSLProtocol +TLSv1 +TLSv1.1 +TLSv1.2
Save the files and restart Oracle HTTP Server.
If you are editing files manually, ensure you edit a currently configured value instead of adding another. It could be easy to add a global parameter when it will be overridden by a value in the VirtualHost.
You must edit the
admin.conf files, but note that you might have other customized
.conf files and/or have another product installed and configured using its own
You can also use FMW Control to edit the configuration and choose
TLSv1 for the VirtualHost ports used for SSL. However, if you attempt to modify the built-in *.9999 VirtualHost, then you will be presented with a alert stating
You cannot edit or delete a virtual host of type ADMIN. In this case, you must manually edit the
>/admin.conf file to add the
SSLProtocol TLSv1 configuration.