6
Security and J2EE Applications

This chapter describes security issues affecting J2EE applications in Oracle Application Server Containers for J2EE (Oracle Application Server Containers for J2EE).

This chapter contains these topics:

• Introduction

• Security Considerations During Development and Deployment

• OC4J and the JAAS Provider

• Authentication in the J2EE Environment

• Authorization in the J2EE Environment

Introduction

When the JAAS Provider is integrated with applications developed for the Java 2 Platform, the following Oracle components are available to developers:

• The JAAS Provider, which provides support for storage, retrieval, and administration of realm information (users and roles) and policy information (permissions). The JAAS Provider supports two possible repositories or provider types:
  • XML-based Provider Type

  • LDAP-based Oracle Internet Directory (available only with OracleAS Infrastructure installation)

• Login modules, such as the JAAS Provider RealmLoginModule

  See Also: "Provider Types" for further information about provider types Oracle Application Server 10g Security Guide for information on installing Oracle Internet Directory.

Security Considerations During Development and Deployment

The JAAS Provider is designed to work with the J2EE declarative security model. This declarative model requires little or no programming to use JAAS security in your application. Instead, most security decisions are made as part of the deployment process, making it easy to make changes without requiring re-coding. If the declarative model is not sufficient, the JAAS Provider also supports programmatic security in the same manner that JAAS is used in any J2SE environment.

Development

If your application relies on the declarative security model (where J2EE security roles are defined in deployment descriptors, such as web.xml), the developer must determine if the application uses application-specific roles. If so, the developer must define these roles so that they can be mapped to the J2EE logical roles during the deployment phase.

If your application uses JAAS programmatically, then the developer must create a JAAS LoginContext and explicitly call the login() method to invoke a JAAS LoginModule.

Deployment

Using the declarative security model, the deployer must make the following security-related decisions:

• Determine the J2EE logical roles that are assumed in the application, then define these roles in the deployment descriptors. For example, an HR application may assume that the J2EE logical role hr_manager is running the application; the deployer must define that role.

• Determine the authorization constraints that apply to these roles and define them in the deployment descriptors. For web modules, these constraints typically apply to URL patterns as defined in the J2EE specification. EJB modules typically have constraints at the EJB-method level.

• Decide whether to use an XML flat file or OID (LDAP) as the repository for the JAAS Provider. This also determines which provider, XML-based or LDAP-based, and user manager the application uses.

• Map the security roles (including the application-specific roles, if they exist) to users and groups defined by the OC4J user manager (for instance, JAZNUserManager). For example, the J2EE logical role called hr_manager may be mapped to a given set of users defined by the OC4J user manager.

For information on making and implementing these decisions, see Chapter 3, "Configuring And Deploying the JAAS Provider"; for a full discussion of deployment, see the Oracle Application Server Containers for J2EE User's Guide.

OC4J and the JAAS Provider

Oracle Application Server Containers for J2EE is a J2EE container that accepts HTTP and RMI client connections. These connections permit access to servlets, Java Server Pages (JSPs), and Enterprise JavaBeans (EJBs).

J2EE containers separate business logic from resource and lifecycle management. This enables developers to focus on writing business logic, rather than writing enterprise infrastructure. For example, Java servlets simplify Web development by providing an infrastructure for component, communication, and session management in a Web container integrated with a Web server.

OC4J Integration

The JAAS Provider is integrated with Oracle Application Server Containers for J2EE to enhance application security. This integration provides the following benefits:

• Integration with single sign-on (SSO)

• Fine-grained access control through Java 2 permissions

• run-as identity support, delegation support (from servlet to Enterprise JavaBeans)

• Secure file-based storage of user passwords

JAZNUserManager

Another key component of JAAS integration in the J2EE environment is JAZNUserManager. JAZNUserManager is an implementation of the Oracle Application Server Containers for J2EE UserManager interface.

Replacing principals.xml

The OC4J principals.xml file is less secure and less flexible than authentication with JAZNUserManager. JAZNUserManager provides the following:

• Secure storage of obfuscated passwords

• Full role-based access control (RBAC), including hierarchical roles

• Full support for the Java 2 permission model and JAAS

• Secure implementation based on the Java 2 permission model, allowing non-trusted (or partially trusted) code to run in the same JVM as the JAAS Provider

  Note:: We strongly encourage you to migrate your existing applications from using principals.xml to using JAZNUserManager. For instructions, see "Migrating Principals from the principals.xml File (XML-based Provider Only)".

JAZNUserManager Features

In addition to the features mentioned in "Replacing principals.xml", JAZNUserManager provides many other features, including:

• Single Sign-On (SSO) integration with Oracle Application Server Containers for J2EE

• RealmLoginModule integration in non-SSO environments

• Support for custom login modules

• Identity propagation

• Location, reading, editing, removal, and management of user and group objects

• Enforcement of security constraints

Authentication Environments

The JAAS Provider integrates with three different login authentication environments in a J2EE application.

• SSO

  Uses OracleAS Single Sign-On to authenticate logins

• SSL
  • Uses Secure Socket Layers for client certificate-based authentication

  • Uses a login module (for example, RealmLoginModule) to authenticate logins

• Basic Authentication
  • Prompts user directly for username and password, without going through OracleAS Single Sign-On

  • Uses a login module (for example, RealmLoginModule) to authenticate logins

The following sections discuss how the JAAS Provider integrates with each of these authentication types.

Integrating the JAAS Provider with SSO-Enabled Applications

SSO lets a user access multiple accounts and applications with a single set of login credentials. Figure 6-1 shows JAAS integration in an application running in an SSO-enabled J2EE environment.

Figure 6-1 Oracle Component Integration in SSO-Enabled J2EE Environments

Text description of the illustration jaz001.gif

SSO-Enabled J2EE Environments: A Typical Scenario

This section describes the responsibilities of Oracle components when an HTTP client request is initiated in an SSO-enabled J2EE environment.

1. An HTTP client attempts to access a Web application, WebApp A1, hosted by Oracle Application Server Containers for J2EE (the Web container for executing servlets). Oracle HTTP Server (using an Apache listener) handles the request.

2. mod_osso/Oracle HTTP Server receives the request and:
   • Determines that WebApp A1 application requires Web-based SSO for authenticating HTTP clients

   • Redirects the HTTP client request to the Web-based SSO OracleAS Single Sign-On (because it has not yet been authenticated).

3. The HTTP client is authenticated by OracleAS Single Sign-On through HTTP or public key infrastructure (PKI) Authentication. OracleAS Single Sign-On then:
   • Validates the user's stored login credentials

   • Sets the SSO cookie (including the user's distinguished name and realm)

   • Redirects back to the WebApp A1 application (in Oracle Application Server Containers for J2EE)

4. The JAAS Provider retrieves the SSO user.

5. The final step or steps depend on the setting of the runas-mode in the <jazn-web-app> element.

   If the runas-mode is set to false, then the following happens:

   1. The target servlet is invoked.

      If the runas-mode is set to true, then the following happens:

   2. The JAAS Provider invokes the target servlet within a PrivilegedAction block through Subject.doAs(). The JAZNUserManager enforces security constraints.
      • When Subject.doAs() is called, JAAS consults the JAAS Provider for permissions associated with the SSO user through the getPermissions() method.

      • The JAAS Provider retrieves the permissions associated with the given grantee from the provider type (LDAP-based or XML-based), and updates the policy cache as appropriate. The JAAS Provider then returns the granted set of permissions to the JAAS Provider runtime.

      • The JAAS Provider runtime constructs a new AccessControlContext based on the permissions returned from getPermissions().

   3. The servlet's code runs under the AccessControlContext of the SSO user.

   4. If the servlet's code attempts to write to a file in the operating system's file system, then this triggers a call to SecurityManager.checkPermission().

   5. The JVM then:
      • Examines the authorization context associated with the current thread

      • Determines that the current subject has the required permissions to write to the file

   6. SecurityManager.checkPermission() returns safely and the client HTTP request proceeds.

Integrating the JAAS Provider with SSL-Enabled Applications

SSL is an industry standard protocol for managing the security of message transmission on the Internet. Figure 6-2 shows JAAS integration in an application running in an SSL-enabled J2EE environment.

Figure 6-2 Oracle Component Integration In SSL-Enabled J2EE Environments

Text description of the illustration jaz010.gif

SSL-Enabled J2EE Environments: A Typical Scenario

This section describes the responsibilities of Oracle components when an HTTP client request is initiated in an SSL-enabled J2EE environment. In this environment, OracleAS Single Sign-On is not used. A login module (for example, RealmLoginModule) is used.

1. An HTTP client attempts to access a Web application (named WebApp A1) hosted by Oracle Application Server Containers for J2EE (the Web container for executing servlets). Oracle HTTP Server (using an Apache listener) handles the request.

2. mod_ossl/Oracle HTTP Server receives the request and determines that the WebApp A1 application requires SSL server authentication for HTTP clients.

3. If a server and/or client wallet certificate is configured, the HTTP client is prompted to accept the server certificate of OHS and provide the client certificate.

4. The JAAS Provider retrieves the SSL client certificate.

5. The JAAS Provider retrieves the SSL user from the certificate.

6. The final step or steps depend on the runas-mode specified in the <jazn-web-app> element.

   If runas-mode is set to false, then the target servlet is invoked.

   If runas-mode is set to true, then the following happens:

   1. The JAAS Provider invokes the target servlet within a PrivilegedAction block through Subject.doAs(). The JAZNUserManager enforces security constraints.
      • When Subject.doAs() is called, the method consults for permissions associated with the SSL user through the getPermissions() method.

      • The JAAS Provider retrieves the permissions associated with the given grantee from the provider type (LDAP-based or XML-based), and updates the policy cache as appropriate. The JAAS Provider then returns the granted set of permissions to the JAAS Provider runtime.

      • The JAAS Provider runtime constructs a new AccessControlContext based on the permissions returned from getPermissions().

   2. The servlet's code runs under the AccessControlContext of the SSL user.

   3. If the servlet's code attempts to write to a file in the operating system's file system, then this triggers a call to SecurityManager.checkPermission().

   4. The JVM then:
      • Examines the authorization context associated with the current thread

      • Determines that the current subject has the required permissions to write to the file

   5. SecurityManager.checkPermission() returns safely and the client HTTP request proceeds.

Integrating the JAAS Provider with Basic Authentication

Basic authentication bypasses OracleAS Single Sign-On. Figure 6-3 shows specific JAAS integration in an application configured for Basic authentication in a J2EE environment.

Figure 6-3 Oracle Component Integration in j2ee Environment

Text description of the illustration jaz011.gif

Basic Authentication J2EE Environments: Typical Scenario

This section describes the responsibilities of Oracle components when an HTTP client request is initiated in a J2EE environment configured for Basic authentication. In this environment, OracleAS Single Sign-On is not used. A login module (for example, RealmLoginModule) is used.

Note: If you have configured Basic authentication, OC4J invokes the RealmLoginModule whenever the user credentials are required. For example, when a request hits a protected page, OC4J will ask the JAAS Provider to authenticate the user, then the RealmLoginModule will be invoked to authenticate the user, using the credentials sent by the user via the browser over HTTP.

1. An HTTP client attempts to access a Web application (named WebApp A1) hosted by Oracle Application Server Containers for J2EE (the Web container for executing servlets).

2. The JAAS Provider retrieves the user.

3. The final step or steps depend on the setting of the runas-mode in the jazn-web-app element.

   If the runas-mode is set to false, then the following happens:

   1. The target servlet is invoked.

   If the runas-mode is set to true, then the following happens:

   1. The JAAS Provider invokes the target servlet's service() method within a PrivilegedAction block through Subject.doAs(). The JAZNUserManager enforces security constraints.
      • When Subject.doAs() is called, JAAS consults the JAAS Provider for permissions associated with the SSO user through the getPermissions() method.

      • The JAAS Provider retrieves the permissions associated with the given grantee from the provider type (LDAP-based or XML-based), and updates the policy cache as appropriate. The JAAS Provider then returns the granted set of permissions to the JAAS Provider runtime.

      • The JAAS Provider runtime constructs a new AccessControlContext based on the permissions returned from getPermissions().

   2. The servlet's code runs under the AccessControlContext of the user.

   3. The servlet's code attempts to write to a file in the operating system's file system, triggering a call to SecurityManager.checkPermission().

   4. The JVM then:
      • Examines the authorization context associated with the current thread

      • Determines that the current subject has the required permissions to write to the file

   5. SecurityManager.checkPermission() returns safely and the client HTTP request proceeds.

      See Also: Your Sun Java documentation for more information on J2EE by visiting the following URL: http://java.sun.com/j2ee/

J2EE and JAAS Provider Role Mapping

Two distinct role types are available to application developers creating JAAS-integrated applications in J2EE environments: J2EE roles and JAAS roles. When these role types are mapped together using Oracle Application Server Containers for J2EE group mappings, users can access an application with a defined set of role permissions for as long as the user is mapped to this role.

This section describes these role types and how which they are mapped together.

• J2EE Security Roles

• JAAS Provider Roles and Users

• Oracle Application Server Containers for J2EE Group Mapping to J2EE Security Roles

J2EE Security Roles

The J2EE development environment includes a portable security roles feature defined in the web.xml file for servlets and Java Server Pages (JSPs). Security roles define a set of resource access permissions for an application. Associating a principal (in this case, a JAAS user or role) with a security role assigns the defined access permissions to that principal for as long as they are mapped to the role. For example, an application defines a security role called sr_developer:

<security-role>
     <role-name>sr_developer</role-name>
</security-role>  
 

You also define the access permissions for the sr_developer role.

 <security-constraint>
    <web-resource-collection>
      <web-resource-name>access to the entire application</web-resource-name>
      <url-pattern>/*</url-pattern>
    </web-resource-collection>
        <!-- authorization -->
    <auth-constraint>
      <role-name>sr_developer</role-name>
    </auth-constraint>
  </security-constraint>

JAAS Provider Roles and Users

JAAS roles and users are defined depending on the provider type, LDAP-based or XML-based.

For example, with the XML-based provider type, developer is listed as a role element in the jazn-data.xml file:

<role>
  <name>developer</name>
  <members>
    <member>
      <type>user<type>
      <name>john<name>
    </member>
  </members>
</role>

Oracle Application Server Containers for J2EE Group Mapping to J2EE Security Roles

Oracle Application Server Containers for J2EE enables you to map portable J2EE security roles defined in the J2EE web.xml file to groups in an orion-application.xml file.

The roles and users defined in your provider environment are mapped to the Oracle Application Server Containers for J2EE developer group role in the orion-application.xml file.

For example, the sr_developer security role is mapped to the group named developer.

<security-role-mapping name="sr_developer">
       <group name="developer" />
  </security-role-mapping>

Notice that a <group> in a <security-role-mapping> element corresponds to a role in the JAAS provider. Therefore, this association permits the developer group to access the resources allowed for the sr_developer security role.

In this paradigm, the user john is listed as a member of the developer role. Because the developer group is mapped to the J2EE security role sr_developer in the orion-application.xml file, john has access to the application resources defined by the sr_developer role.

Authentication in the J2EE Environment

Authentication is the process of verifying the identity of a user in a computing system, often as a prerequisite to granting access to resources in a system. User authentication in the J2EE environment is performed by the following:

• OracleAS Single Sign-On (for SSO environments) or the JAAS Provider RealmLoginModule or other login module (for non-SSO environments)

  Before HTTP requests can be dispatched to the target servlet, the JAZNUserManager gets the authenticated user information (set by mod_osso) from the HTTP request object and sets the JAAS subject in Oracle Application Server Containers for J2EE.

• One of the following:
  • JAZNUserManager

  • XMLUserManager

  • A developer-supplied UserManager

Running with an Authenticated Identity

You can choose to configure the JAZNUserManager so that a filter enables the target servlet to run with the permissions and roles associated with an authenticated identity or run-as identity. To do this, configure the jazn-web-app element.

See Also: "JAZNUserManager" for further information on options and configuration of the JAZNUserManager filter, including the jazn-web-app element.

Retrieving Authentication Information

The following javax.servlet.HttpServletRequest APIs retrieve authentication information within the servlet:

• getRemoteUser for the authenticated username

• getAuthType for the authentication scheme

• getUserPrincipal for the authenticated principal object

• getAttribute("java.security.cert.X509certificate") for the SSL client certificate

Authorization begins with a call to Subject.doAs().

Authorization in the J2EE Environment

Authorization is the process of granting the permissions and privileges entitled to the user. This section discusses authentication within servlets.

If the servlet is configured to permit doAs(), the JAZNUserManager invokes an authenticated target servlet within a Subject.doAs() block to enable JAAS-based authorization in the target servlets.

Authorization is achieved through the following:

• JAZNUserManager

• Methods based on the Java 2 Security Model:
  • Servlet.service() in the servlet

  • Subject.doAs() and Subject.doAsPrivileged() in the client

  • SecurityManager.checkPermission()in the server

    See Also: Configuring Servlet Authorization (runas-mode and doasprivileged-mode) in <jazn-web-app> .