This chapter contains an overview of Oracle HTTP Server security features and provides configuration information for setting up a secure website.
This chapter includes the following sections:
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 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. 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.
Users who have been authenticated through Oracle Access Manager. These users have access to resources allowed by Single Sign-On.
You can configure Oracle HTTP Server to protect all resources that it manages. You are responsible for configuring any protection that your resources require.
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. 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.
See Also:
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.
Access control refers to any means of controlling access to any resource.
See Also:
For more information on how to authenticate users, see the Apache HTTP Server documentation on "Authentication and Authorization" at: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.
When OraAuditEnable is set to Off, auditing is disabled regardless of the settings in auditconfig.xml.
You can configure audit filters by using Fusion Middleware Control or by editing the auditconfig.xml file directly.
See Also:
"Overview of Audit Features" in Securing Applications with Oracle Platform Security ServicesOracle 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 Section 2.6, "mod_ossl." For information on the directives available under mod_ossl, see Section F.3, "mod_ossl Module."
The mod_wl_ohs module also contains a configuration for SSL. For more information, see "Using SSL with Plug-ins" and "Parameters for Web Server Plug-Ins" in Using Oracle WebLogic Server Proxy Plug-Ins 12.1.3.
This section 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. 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. For more information, see Section F.3.9, "SSLTraceLogLevel."
Note:
SSL logs will work when OHS logs is set for INFO or higher level.mod_security is an open-source module that you can use to detect and prevent intrusion attacks against Oracle HTTP Server; for example, you can specify 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.
For more information on mod_security, see Section 5.4, "Configuring mod_security".