J2EE Security

By Bill Shannon

Date: Nov 26, 2003

Sample Chapter is provided courtesy of Addison Wesley.

Return to the article

This chapter from "Java™ 2 Platform, Enterprise Edition: Platform and Component Specifications" describes the security requirements for the Java™ 2 Platform, Enterprise Edition (J2EE).

This chapter describes the security requirements for the Java™ 2 Platform, Enterprise Edition (J2EE).

The J2EE product provider is responsible for determining the level of security and security assurances afforded by their implementation. However, a J2EE product provider is required to satisfy the requirements specified in this chapter.

J2EE.3.1 Introduction

An enterprise contains many resources that can be accessed by many users. Sensitive information often traverses unprotected open networks (such as the Internet). In such an environment, almost every enterprise has security requirements and specific mechanisms and infrastructure to meet them. Although the quality assurances and implementation details may vary, they all share some of the following characteristics:

This chapter specifies how the J2EE platform addresses some of these security requirements, and identifies those requirements left to be addressed by J2EE product providers. Issues being considered for future versions of this specification are briefly mentioned in Section J2EE.3.7, “Future Directions.”

J2EE.3.2 A Simple Example

The security behavior of a J2EE environment may be better understood by examining what happens in a simple application with a web client, JSP page user interface, and enterprise bean business logic. We include here a descriptive example; this example is not meant to specify requirements. In this example, the web client relies on the web server to act as its authentication proxy by collecting user authentication data from the client and using it to establish an authenticated session.

Step 1. Initial Request

The web client requests the main application URL, shown in Figure J2EE.3-1.

01fig03.gifFigure J2EE.3-1. Initial Request

Since this client has not yet authenticated itself to the application environment, the server responsible for delivering the web portion of the application (hereafter referred to as “web server”) detects this and invokes the appropriate authentication mechanism for this resource.

Step 2. Initial Authentication

The web server returns a form that the web client uses to collect authentication data (e.g., username and password) from the user. The web client forwards the authentication data to the web server, where it is validated by the web server, as shown in Figure J2EE.3-2.

01fig04.gifFigure J2EE.3-2. Initial Authentication

This validation mechanism could be local to the server, or it could leverage the underlying security services. The web server then sets a credential for the user.

Step 3. URL Authorization

The web server determines if the user whose identity is captured in the credential is authorized to access the resource represented by the URL. The web server performs the authorization decision by consulting the security policy (derived from the deployment descriptor) associated with the web resource to determine the security roles that are permitted access to the resource. The web container then tests the user’s credentials against each role to determine if it can map the user to the role. Figure J2EE.3-3 shows this process.

01fig05.gifFigure J2EE.3-3. URL Authorization

The evaluation stops with an “is authorized” outcome on the first role that the web container is able to map the user to. A “not authorized” outcome is reached if the web container is unable to map the user to any of the permitted roles.

Step 4. Fulfilling the Original Request

If the user is authorized, the web server returns the result of the original URL request, as shown in Figure J2EE.3-4.

01fig06.gifFigure J2EE.3-4. Fulfilling the Original Request

In this case, the response of a JSP page is returned. Next, the user performs some action (perhaps posting form data) that needs to be handled by the business logic component of the application.

Step 5. Invoking Enterprise Bean Business Methods

When the JSP page performs the remote method call to the enterprise bean, the user’s credential is used to establish (as shown in Figure J2EE.3-5) a secure association between the JSP page and the enterprise bean. The association is implemented as two related security contexts, one in the web server and one in the EJB container.

01fig07.gifFigure J2EE.3-5. Invoking an Enterprise Bean Business Method

The EJB container is responsible for enforcing access control on the enterprise bean method; it does so by consulting the security policy (derived from the deployment descriptor) associated with the enterprise bean to determine the security roles that are permitted access to the method. Then for each role, the EJB container will use the security context associated with the call to determine if it can map the caller to the role. The evaluation stops with an “is authorized” outcome on the first role that the EJB container is able to map to the caller. A “not authorized” outcome is reached if the container is unable to map the caller to any of the permitted roles and results in an exception being thrown by the container, and propagated back to the caller (in this case the JSP page). If the call “is authorized,” the container dispatches control to the enterprise bean method, which then returns a result to the caller.

The platform provides two sets of methods for use by security aware applications: the EJBContext methods isCallerInRole and getCallerPrincipal available to enterprise beans through the EJB container, and the HttpServletRequest methods isUserInRole and getUserPrincipal available to servlets and JSP pages through the web container. When an enterprise bean calls the isCallerInRole method, the enterprise bean container determines if the caller (as represented by the security context) is in the specified role. When an enterprise bean calls the getCallerPrincipal method, the enterprise bean container returns the principal associated with the security context. The web container APIs behave similarly.

J2EE.3.3 Security Architecture

This section describes the J2EE security architecture on which the security requirements defined by this specification are based.

J2EE.3.3.1 Goals

  1. Portability: The J2EE security architecture must support the Write Once, Run Anywhere™ application property.

  2. Transparency: Application component providers should not have to know anything about security to write an application.

  3. Isolation: The J2EE platform will perform authentication and access control, and its ability to do so will be established by the deployer and managed by the system administrator.

    By divorcing responsibility for security from the application, this specification ensures greater portability of J2EE applications.

  4. Extensibility: The use of platform services by security aware applications must not compromise application portability. For applications that need access to information available in the security environment, this specification provides APIs in the component programming model for the purpose of interacting with container/server security information. Applications that restrict their interactions to the provided APIs should retain portability.

  5. Flexibility: Mechanisms and declarations of security properties of applications should not impose a particular security policy, but facilitate the implementation of security policies specific to the particular J2EE installation.

  6. Abstraction: A component’s security requirements are logically specified using deployment descriptors. Security roles and access requirements are mapped into environment specific security roles, users, and policies. A deployer may choose to modify the security properties to be consistent with the deployment environment. The deployment descriptor should document which parameters can be modified and which should not.

  7. Independence: Required security behaviors and deployment contracts should be implementable using a variety of popular security technologies.

  8. Compatibility testing: The J2EE security requirements architecture must be expressed in a manner that allows for an unambiguous determination of whether or not an implementation is compatible.

J2EE.3.3.2 Non Goals

  1. This specification does not dictate a specific security policy. Security policy for applications and for enterprise information systems varies for many reasons. This specification allows product providers to provide people the technology to implement and administer the policies they require.

  2. This specification does not mandate a specific security technology, such as Kerberos, PK, NIS+, NTLM, etc.

  3. This specification does not require that the J2EE security behaviors be universally implementable (i.e., using any or all security technologies).

  4. This specification does not afford any warranty or assurance of the effective security of a J2EE product.

  5. This specification does not require support for secure interactions between enterprise beans running on different but compatible J2EE products. (We expect this to be a goal of the next version of this specification.)

J2EE.3.3.3 Terminology

This section introduces the terminology that is used to describe the security requirements of the J2EE platform.

J2EE.3.3.4 Container Based Security

To achieve the goals for security in a J2EE environment, security for components is provided by their containers. A container provides security in two forms:

J2EE.3.3.5 Declarative Security

Declarative security refers to the means of expressing an application’s security structure, including security roles, access control, and authentication requirements in a form external to the application. The deployment descriptor is the primary vehicle for declarative security in the J2EE platform.

A deployment descriptor is a contract between an application component provider and a deployer or application assembler. In the context of J2EE security, it can be used by an application programmer to represent an application’s security related environmental requirements. Groups of components are associated with a deployment descriptor.

The application’s logical security requirements are mapped by a deployer to a representation of the security policy that is specific to the environment at deployment time. A deployer uses a deployment tool to process the deployment descriptor.

At runtime, the container uses the security policy that was derived from the deployment descriptor and configured by the deployer to enforce authorization (see Section J2EE.3.3.8, “Authorization Model”).

J2EE.3.3.6 Programmatic Security

Programmatic security is used by security aware applications. Programmatic security is useful when declarative security alone is not sufficient to express the security model of the application. Programmatic security consists of two methods of the EJB EJBContext interface and two methods of the servlet HttpServletRequest interface:

These methods allow components to make business logic decisions based on the security role of the caller or remote user. They also allow the component to determine the principal name of the caller or remote user to use as a database key, for example. (Note that the form and content of principal names will vary widely between products and enterprises, and portable components will not depend on the actual contents of a principal name.)

J2EE.3.3.7 Distributed Security

Some product providers may produce J2EE products in which the containers for various component types are distributed. In a distributed environment, communication between J2EE components can be subject to security attacks (for example, data modification and replay attacks).

Such threats can be countered by using a secure association to secure communications. A secure association is shared security state information which permits secure communication between two components. Establishing a secure association could involve several steps such as:

  1. Authenticating the target principal to the client and/or authenticating the client to the target principal

  2. Negotiating a quality of protection, such as confidentiality or integrity

  3. Establishing a security context between the components

Since a container provides security in J2EE, secure associations for a component are typically established by a container. Secure associations for web access are specified here. This specification does not specify how or when such secure associations are formed for access to enterprise beans.

A J2EE product provider may allow control over the quality of protection or other aspects of secure association at deployment time. These aspects depend upon the application and are essentially application requirements. Applications can specify their quality of protection requirements for access to web resources using elements in their deployment descriptor. This specification does not define any mechanisms that an application component provider can use to communicate an enterprise bean’s requirements for secure associations.

J2EE.3.3.8 Authorization Model

The J2EE authorization model is based on the concept of security roles. A security role is a logical grouping of users that is defined by an application component pro-vider or assembler. It is then mapped by a deployer to security identities (e.g., principals, groups, etc.) in the operational environment. A security role can be used either with declarative security or with programmatic security.

Declarative authorization can be used to control access to an enterprise bean method and is specified in the deployment descriptor. An enterprise bean method can be associated with a method-permission element in the deployment descriptor. The method-permission element contains a list of methods that can be accessed by a given security role. If the calling principal is in one of the security roles allowed access to a method, the principal is allowed to execute the method. Conversely, if the calling principal is in none of the roles, the caller is not allowed to execute the method. Access to web resources can be protected in a similar manner.

A security role can be used in the EJBContext method isCallerInRole and the HttpServletRequest method isUserInRole. Each method returns true if the calling principal is in the specified security role.

J2EE.3.3.9 Role Mapping

Enforcement of either programmatic or declarative security depends upon determining if the principal associated with an incoming request of an enterprise bean or web resource is in a given security role or not. A container makes this determination based on the security attributes of the calling principal. For example,

  1. A deployer could have mapped a security role to a user group in the operational environment. In this case, the user group to which the calling principal belongs is retrieved from its security attributes. If the principal’s user group matches the user group in the operational environment that the security role has been mapped to, the principal is in the security role.

  2. A deployer could have mapped a security role to a principal name in a security policy domain. In this case, the principal name of the calling principal is retrieved from its security attributes. If this principal is the same as the principal name to which the security role was mapped, the calling principal is in the security role.

The source of security attributes may vary across implementations of the J2EE platform. Security attributes could have been transmitted in the calling principal’s credential or in the security context. If security attributes are not transmitted, they may be retrieved from a trusted third party such as a directory service or security service.

J2EE.3.3.10 HTTP Login Gateways

Secure interoperability between enterprise beans in different security policy domains is not addressed in this specification. A future version will specify an interoperability protocol (based on industry standards) that will allow EJB containers in different domains to interoperate securely.

To gain access to another J2EE product that may be incompatible (i.e., in terms of communications protocols, security technology, or policy domain), a component may choose to log in to a foreign server via HTTP. HTTP over SSL can be used to provide secure, interoperable communication between J2EE products from different providers. An application component can be configured to use SSL mutual authentication when accessing a remote resource using HTTP. Applications using HTTP in this way may want to exchange data using XML or some other structured format, rather than HTML.

We call this use of HTTP with SSL mutual authentication to access a remote service an HTTP Login Gateway. Requirements in this area are specified in Section J2EE.3.4.1, “Web Clients.”

J2EE.3.3.11 User Authentication

User authentication is the process by which a user proves his or her identity to the system. This authenticated identity is then used to perform authorization decisions for accessing J2EE application components. An end user can authenticate using either of the two supported client types:

J2EE.3.3.11.1 Web Client

A web client can authenticate a user to a web server using one of the following mechanisms:

HTTP digest authentication is not widely supported by web browsers and hence is not required.

The deployer or system administrator determines which method to apply to an application or groups of applications. A web client can employ a web server as its authentication proxy. In this case, the client’s credentials are established for the client in the server, where they may be used by the server to perform authorization decisions, to act as the client in calls to enterprise beans, or to negotiate secure associations with resources.

Current web browsers commonly rely on proxy authentication.

HTTP Basic Authentication HTTP basic authentication is the authentication mechanism supported by the HTTP protocol. This mechanism is based on a username and password. A web server requests a web client to authenticate the user. As part of the request, the web server passes the realm in which the user is to be authenticated. The web client obtains the username and the password from the user and transmits them to the web server. The web server then authenticates the user in the specified realm (referred to as HTTP Realm in this document).

HTTP basic authentication is not secure. Passwords are sent with a simple base64 encoding. The target server is not authenticated. Additional protection can be applied to overcome these weaknesses. For example, the password may be protected by applying security at the transport layer (e.g., HTTPS) or at the network layer (e.g., IPSEC or VPN).

Despite its limitations, the HTTP basic authentication mechanism is included in this specification because it is widely used in many form based applications.

HTTPS Authentication End user authentication using HTTPS (HTTP over SSL) is a strong authentication mechanism. This mechanism requires the user to possess a public key certificate (PKC). Currently, PKC is rarely used by end users on the Internet. However, it is useful in e-commerce applications and also for single signon from within the browser. For these reasons, it is a required feature of the J2EE platform.

Form Based Authentication The look and feel of the “login screen” cannot be controlled with the web browser’s built-in authentication mechanisms. This specification introduces the ability to package a standard HTML or servlet/JSP based form for logging in. The login form allows customization of the user interface. The form based authentication mechanism is described in the servlet specification.

Web Single Signon HTTP is a stateless protocol. However, many web applications need support for sessions that can maintain state across multiple requests from a client. Therefore, it is desirable to:

  1. Make login mechanisms and policies a property of the environment the web application is deployed in.

  2. Be able to use the same login session to represent a user to all the applications that they access.

  3. Require the user to re-authenticate only when crossing a security policy domain.

Credentials that are acquired through a web login process are associated with the session. The container uses these credentials to establish a security context for the session. The container uses the security context to determine authorization for access to web resources and for the establishment of secure associations with other components or with enterprise beans.

Login Session In the J2EE platform, session support is provided by a servlet container. When a user successfully authenticates with a web server, the container establishes a login session context for the user. The login session contains the credentials associated with the user. 1

J2EE.3.3.11.2 Application Client

Application clients (described in detail in Chapter J2EE.9) are client programs that may directly (i.e., without the help of a web browser and without traversing a web server) interact with enterprise beans. Of course, application clients may also access web resources.

Application clients, like the other J2EE application component types, execute in a managed environment that is provided by an appropriate container. Application clients are expected to have access to a graphical display and input device and can expect to communicate with a human user.

Application clients are used to authenticate the end user to the J2EE platform, for instance when accessing protected web resources or enterprise beans.

J2EE.3.3.11.3 Lazy Authentication

There is a cost associated with authentication. For example, an authentication process may require exchanging multiple messages across the network. Therefore, it is desirable to perform authentication only when necessary (i.e., lazy authentication). With lazy authentication, an end user is not required to authenticate until the user tries to access a protected resource.

Lazy authentication can be used by first tier clients (applets, application clients) when they access protected resources that require authentication. When a user tries to access such a resource, the user can be asked to provide the needed authentication data. If a user is successfully authenticated, they are allowed to access the resource.

J2EE.3.4 User Authentication Requirements

J2EE.3.4.1 Web Clients

The J2EE product provider must support several methods of web based user authentication.

J2EE.3.4.1.1 Web Single Signon

All J2EE compatible web servers must support single signon by maintaining a login session for each web user. This allows applications to remain independent of the details of implementing and securing login information. This also provides the J2EE product provider with the flexibility to choose authentication mechanisms independent of the applications secured by these mechanisms. It must be possible for one login session to span more than one application, allowing a user to log in once and access multiple applications.

J2EE.3.4.1.2 Login Sessions

All J2EE products must support login sessions as described in the servlet specification.

Lazy authentication must be supported by web servers for protected web resources. If authentication is required, then one of the three required login mechanisms listed in the next section may be used.

J2EE.3.4.1.3 Required Login Mechanisms

All J2EE products are required to support three login mechanisms: HTTP basic authentication, SSL mutual authentication, and form-based login. An application is not required to use any of these mechanisms, but they are required to be available for any application’s use.

HTTP Basic Authentication All J2EE products are required to support HTTP basic authentication (RFC2068). Platform Providers are also required to support basic authentication over SSL.

SSL Mutual Authentication SSL 3.0 2 and the means to perform mutual (client and server) certificate based authentication are required by this specification.

All J2EE products must support the following cipher suites to ensure interoperable authentication with clients:

These cipher suites are supported by the major web browsers and meet the U.S. government export restrictions.

Form Based Login The web application deployment descriptor contains an element that causes a J2EE product to associate an HTML form resource (perhaps dynamically generated) with the web application. If the deployer chooses this form of authentication (over HTTP basic, or SSL certificate based authentication), this form must be used as the user interface for login to the application.

The form based login mechanism and web application deployment descriptors are described in the Servlet 2.2 specification.

J2EE.3.4.1.4 Unauthenticated Users

Web containers are required to support access to web resources by clients that have not authenticated themselves to the container. This is the common mode of access to web resources on the Internet. A web container reports that no user has been authenticated by returning null from the HttpServletRequest method getUserPrincipal.

The EJB specification requires that the EJBContext method getCallerPrincipal always returns a valid Principal object. It can never return null. However, it’s important that components running in a web container be able to call enterprise beans, even when no user has been authenticated in the web container. When a call is made in such a case from a component in a web container to an enterprise bean, a J2EE product must provide a principal for use in the call.

A J2EE product may provide a principal for use by unauthenticated callers using many approaches, including, but not limited to:

This specification does not specify how a J2EE product should choose a principal to represent unauthenticated users, although future versions of this specification may add requirements in this area.

J2EE.3.4.2 Application Clients

To satisfy the authentication and authorization constraints enforced by the enterprise bean containers and web containers, the application client container must authenticate the application user. The techniques used may vary based on the implementation of the application client container and are beyond the control of the application. The application client container may integrate with a J2EE product’s authentication system, to provide a single signon capability, or the container may authenticate the user when the application is started. The container may delay authentication until it is necessary to access a protected resource or enterprise bean. If the container needs to interact with the user to gather authentication data, the container must provide an appropriate user interface. In this specification, no mechanism is provided to customize the user authentication interface of individual application clients. In a future version of this specification, application clients will be able to use the Java™ Authentication and Authorization Service APIs to access information about the currently authenticated user, to write portable authentication user interfaces, and to participate in and control the authentication process.

Application clients execute in an environment controlled by a J2SE security manager and are subject to the security permissions defined in Table J2EE.6-2, “J2EE Security Permissions Set.” Although this specification does not define the relationship between the operating system identity associated with a running application client and the authenticated user identity, a J2EE product’s ability to relate these identities is a fundamental aspect of single signon.

Additional application client requirements are described in Chapter J2EE.9 of this specification.

J2EE.3.4.3 Resource Authentication Requirements

Resources within an enterprise are often deployed in security policy domains that are different from the security policy domain to which the component belongs. Because the authentication mechanisms used to authenticate the caller to resources can vary widely, a J2EE product must provide the ability to authenticate in the security policy domain of the resource.

A product provider must support both of the following:

  1. Specification of the principal and authentication data for a resource by the deployer at deployment time. A J2EE container must authenticate to the resource using the specified principal and authentication data; the application component must not need to provide this data. If the authentication data is stored by a J2EE container, then its confidentiality is the responsibility of the product provider.

  2. Specification of the principal and authentication data for a resource by the application component at runtime using APIs appropriate to the resource. The application may obtain the principal and authentication data through a variety of mechanisms, including receiving them as parameters, obtaining them from the component’s environment, etc.

J2EE.3.5 Authorization Requirements

To support the authorization models described in this chapter, the following requirements are imposed on J2EE products.

J2EE.3.5.1 Code Authorization

A J2EE product may restrict the use of certain J2SE classes and methods to secure and insure proper operation of the system. The minimum set of permissions that are required for a J2EE product are defined in Section J2EE.6.2, “Java 2 PlatformStandard Edition (J2SE) Requirements, .” All J2EE products must be capable of deploying application components with exactly these permissions.

A J2EE product provider may choose to enable selective access to resources using the J2SE 1.2 protection model. The mechanism used is J2EE product dependent.

A future version of the J2EE deployment descriptor definition (see Chapter J2EE.8) may make it possible to express any additional permissions that a component needs.

J2EE.3.5.2 Caller Authorization

A J2EE product must enforce the access control rules specified at deployment time (see Section J2EE.3.6, “Deployment Requirements”) and more fully described in the EJB and Servlet specifications.

It must be possible to configure a J2EE product so that the propagated caller identity is used in authorization decisions. This is, for all calls to all enterprise beans from a single application within a single J2EE product, the principal name returned by the EJBContext method getCallerPrincipal must be the same as that returned by the first enterprise bean in the call chain. If the first enterprise bean in the call chain is called by a servlet or JSP page, the principal name must be the same as that returned by the HttpServletRequest method getUserPrincipal in the calling servlet or JSP page. (However, if the HttpServletRequest method getUserPrincipal returns null, the principal used in calls to enterprise beans is not specified by this specification, although it must still be possible to configure enterprise beans to be callable by such components.) Note that this does not require delegation of credentials, only identification of the caller. This principal must be the principal used in authorization decisions for access to all enterprise beans in the call chain. The requirements in this paragraph apply only when a J2EE product has been configured to propagate caller identity.

J2EE products may also provide other deployment modes or configuration options in which the original caller identity is not propagated to all components in the call chain. For instance, some enterprise beans may execute with their own identity and corresponding privileges, and that identity may be made available to other enterprise beans that they call.

J2EE.3.6 Deployment Requirements

The deployment descriptor describes the contract between the application component provider or assembler and the deployer. All J2EE products must implement the access control semantics described in the EJB, JSP, and servlet specifications, and provide a means of mapping the deployment descriptor security roles to the actual roles exposed by a J2EE product.

While most J2EE products will allow the deployer to customize the role mappings and change the assignment of roles to methods, all J2EE products must support the ability to deploy applications and components using exactly the mappings and assignments specified in their deployment descriptors.

As described in the EJB specification and the servlet specification, a J2EE product must provide a deployment tool or tools capable of assigning the security roles in deployment descriptors to the entities that are used to determine role membership at authorization time.

Application developers will need to specify (in the application’s deployment descriptors) the security requirements of an application in which some components may be accessed by unauthenticated users as well as authenticated users (as described above in Section J2EE.3.4.1.4, “Unauthenticated Users”). Applications express their security requirements in terms of security roles, which the deployer maps to users (principals) in the operational environment at deployment time. An application might define a role representing all authenticated and unauthenticated users and configure some enterprise bean methods to be accessible by this role.

To support such usage, this specification requires that it be possible to map an application defined security role to the universal set of application principals independent of authentication.

J2EE.3.7 Future Directions

J2EE.3.7.1 Interoperability

Secure interoperability for enterprise beans will be an important goal of the next version of the J2EE specification. We expect a future version of this specification to require support for an industry standard interoperability protocol for enterprise beans. We expect this protocol to be based on the CORBA IIOP protocol.

J2EE.3.7.2 Auditing

This specification does not specify requirements for the auditing of security relevant events, nor APIs for application components to generate audit records. A future version of this specification may include such a specification for products that choose to provide auditing.