8 Managing Application Security

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:

8.1 About Oracle HTTP Server Security

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 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.

Figure 8-1 Steps for Handling URL Requests in Oracle HTTP Server

Description of Figure 8-1 follows
Description of "Figure 8-1 Steps for Handling URL Requests in Oracle HTTP Server"

8.2 Classes of Users and Their Privileges

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 http.conf file.

  • Users that have been authenticated through mod_osso and Single Sign-On server. These users have access to resources allowed by Single Sign-On.

8.3 Resources Protected

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.

  • Content generated by modules within Oracle HTTP Server. Modules such as mod_perl, mod_dms generate responses that are returned to the client.

  • 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.

8.4 Authentication, Authorization and Access Control

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.

8.4.1 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.

8.4.2 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.

8.4.2.1 Using Apache HTTP Server Modules to Authenticate Users

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 authenticate users.

8.4.2.2 Using mod_osso to Authenticate Users

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.

8.4.3 Support for FMW Audit Framework

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

http://download.oracle.com/docs/cd/E14571_01/core.1111/e10043/audintro.htm#JISEC2372