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.

Principal

A principal is an entity that can be authenticated by an authentication protocol in a security service that is deployed in an enterprise. A principal is identified using a principal name and authenticated using authentication data. The content and format of the principal name and the authentication data depend upon the authentication protocol.

Security Policy Domain

A security policy domain (referred to as security domain) is a scope over which security policies are defined and enforced by a security administrator of the security service. A security policy domain is also sometimes referred to as a realm. This specification uses the term security policy domain or security domain.

Security Technology Domain

A security technology domain is the scope over which the same security mechanism (e.g., Kerberos) is used to enforce a security policy. A single security technology domain may include multiple security policy domains, for example.

Security Attributes

A set of security attributes is associated with every principal. The security attributes have many uses (e.g., access to protected resources, auditing of users, etc.). Security attributes can be associated with a principal by an authentication protocol and/or by the J2EE product provider.

The J2EE platform does not specify the security attributes that can be associated with a principal.

Credential

A credential might contain or reference information (security attributes) that can authenticate a principal to additional services. A principal acquires a credential upon authentication or from another principal that allows its credential to be used ( delegation ).

This specification does not specify the contents or the format of a credential, because both can vary widely.

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:

• Declarative security

• Programmatic security

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:

• isCallerInRole (EJBContext)

• getCallerPrincipal (EJBContext)

• isUserInRole (HttpServletRequest)

• getUserPrincipal (HttpServletRequest)

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:

• Web client

• Application client

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 basic authentication

• HTTPS client authentication

• Form based authentication

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]

^[1] This is true where the client is stateless with respect to authentication, and as such, requires that the server act as its proxy and maintain its login context. In this case login session state is made available for use by the client by giving the client a reference (to use with its requests) to its authentication state stored on the server. Cookies or URL rewriting are used to carry such references. If SSL mutual authentication is used as the authentication protocol, the client can manage its own authentication context, and need not depend on references.

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.