7.2. J2EE Platform Security Model
The J2EE platform container provides a set of security-related system services to its applications and clients. These built-in container services simplify application development because they remove the need for the application developer to write the security portion of the application logic.
Security on the J2EE platform is primarily declarative and is specified externally from the application code. Declarative security mechanisms used in an application are expressed via a declarative syntax in a configuration document called a deployment descriptor. The declarative security model has the advantage of enabling you to easily change these declarative settings to match security policy.
Declarative references in the deployment descriptor, rather than program code, define much of the security for a J2EE application. The collection of security declarations forms the security policy for an application. When security is defined declaratively, the container is responsible for performing security and the application does not include code specifically for security operations. Since security references are in the deployment descriptor, developers can modify the security for an application by using tools or changing the deployment descriptor. At deployment, the container uses the application security policy declared in the deployment descriptor to set up the security environment for the J2EE application, just as it uses other references in the deployment descriptor to perform similar services for transactions, remote communication, and so forth. During runtime, the container interposes itself between the client calls and the application's components to perform security checks and otherwise manage the applications.
In addition to declarative security, the J2EE platform includes APIs to add security code into your components. Programmatic security refers to security decisions that are made by security-aware applications. Programmatic security, which allows an application to include code that explicitly uses a security mechanism, is useful when declarative security alone cannot sufficiently express the security model of an application. The J2EE programming model offers some programmatic services that help you to write security functionality into the application code.
As noted, rather than inventing new security mechanisms, the J2EE platform facilitates the incorporation of existing security mechanisms into an application server operational environment. That is, the J2EE security model integrates with existing authorization and authentication mechanisms, handling existing user identity information, digital certificates, and so forth. The model provides a unifying layer above other security services, and its coherent programming model hides the security implementation details from application developers. For example, the J2EE security model provides mechanisms to leverage existing Internet security standards such as Secure Sockets Layer (SSL).
In addition, the J2EE platform security model gives you the ability to provide security boundaries. Once you have established these security boundaries, you can map users to their organizational roles and combine users into logical groups according to these roles.
Let's look in more detail at the J2EE platform security services and mechanisms. This security model applies to Web services as well as to the entire J2EE platform. “Security for Web Service Interactions” on page 308 describes how a Web service application can leverage these J2EE security mechanisms.
7.2.1. Authentication
Authentication is the mechanism by which a client presents an identifier and the service provider verifies the client's claimed identity. When the proof occurs in two directions—the caller and service both prove their identity to the other party—it is referred to as mutual authentication.
Typically, a client interaction with a J2EE application accesses a set of components and resource, such as JSPs, enterprise beans, databases, and Web service endpoints. When these resources are protected, as is often the case, a client presents its identity and credentials, and the container determines whether the client meets the criteria for access specified by the authorization rules. The platform also allows lazy authentication, which allows unauthenticated clients to access unprotected resources but forces authentication when these clients try to access protected resources. The platform additionally permits authentication to occur at different points, such as on the Web or EJB tier. The J2EE container handles the authentication based on the requirements declared in the deployment descriptor.
Not only does the container enforce authentication and establish an identity when a client calls a component, but the container also handles authentication when the initially called component makes calls to other components and resources. Processing a client's request to a component might require the component to make a chain of calls to access other resources and components. Each subsequently called component might have its own authentication requirements, and these requirements might differ from those of the initially called component. The J2EE container handles this by establishing an identity with each call along the chain of calls. The J2EE platform allows the client identity established with the initial call's authentication to be associated with subsequent method calls and interactions. That is, the client's authenticated identity can be propagated along the chain of calls.
It is also possible to configure a component to establish a new identity when it acts as a client in a chain of calls. When so configured, a component can change the authenticated identity from the client's identity to its own identity. Regardless of how it is handled, the J2EE container establishes an identity for calls made by a component. Also, the J2EE container handles unauthenticated invocations that do not require a client to establish an identity. This mechanism can be useful for supporting use cases where a client does not have to authenticate.
7.2.1.1. Protection Domains
The J2EE platform makes it possible to group entities into special domains, called protection domains, so that they can communicate among themselves without having to authenticate themselves. A protection domain is a logical boundary around a set of entities that are assumed or known to trust each other. Entities in such a domain need not be authenticated to one another.
Figure 7.2 illustrates an environment using protection domains. It shows how authentication is required only for interactions that cross the boundary of a protection domain. Interactions that remain within the protection domain do not require authentication. Although authentication is not required within this realm of trust, there must be some means to ensure that unproven or unauthenticated identities do not cross the protection domain boundary. In the J2EE architecture, a container provides an authentication boundary between external callers and the components it hosts. Furthermore, the architecture does not require that the boundaries of protection domains be aligned with the boundaries of containers. The container's responsibility is to enforce the boundaries, but implementations are likely to support protection domains that span containers.
The container ensures that the identity of a call is authenticated before it enters the protection domain; this is usually done with a credential, such as an X.509 certificate or a Kerberos service ticket. A credential is analogous to a passport or driver's license. The container also ensures that outgoing calls are properly identified. Maintaining proper proof of component identity makes it easier for interacting components to trust each other. A J2EE developer can declaratively specify the authentication requirements of an application for calls to its components (such as enterprise beans or JSPs) and for outbound calls that its components make to access other components and resources.
The deployment descriptor holds declarations of the references made by each J2EE component to other components and to external resources. These declarations, which appear in the descriptor as ejb-ref elements, resource-ref elements, and service-ref elements, indicate where authentication may be necessary. The declarations are made in the scope of the calling component, and they serve to expose the application's inter-component or resource call tree. Deployers use J2EE platform tools to read these declarations, and they can then use these references to properly secure interactions between the calling and called components. The container uses this information at runtime to determine whether authentication is required and to provide the mechanisms for handling identities and credentials.
7.2.1.2. Web Tier Authentication
Developers can specify that authentication be performed on the Web tier when certain components and resources are accessed, in which case the authentication is handled by the J2EE Web container. J2EE Web containers must support three different authentication mechanisms:
HTTP basic authentication— The Web server authenticates a principal using the username and password obtained from the Web client. The username and password are included in the HTTP headers and are handled at the transport layer.
Form-based authentication— A developer can customize a form for entering username and password information, and then use this form to pass the information to the J2EE Web container. This type of authentication, geared toward Web page presentation applications, is not used for Web services.
HTTPS mutual authentication— Both the client and the server use digital certificates to establish their identity, and authentication occurs over a channel protected by Secure Sockets Layer.
Generally, for Web tier authentication, the developer specifies an authorization constraint to designate those Web resources—such as Web service endpoints, HTML documents, Web components, image files, archives, and so forth—that need to be protected. When a user tries to access a protected Web resource, the Web container applies the particular authentication mechanism (either basic, form-based, or mutual authentication) specified in the application's deployment descriptor.
It is important to note that J2EE Web containers provide single sign-on among applications within a security policy domain boundary. Clients often make multiple requests to an application within a session. At times, these requests may be among different applications. In a J2EE application server, when a client has authenticated in one application, it is also automatically authenticated for other applications for which that client identity is mapped. Web containers allow the login session to represent a user for all applications accessible to the user within a single application server without requiring the user to re-authenticate for each application. However, this mechanism is more appropriate for session-aware, browser-based Web applications; it is not as applicable to Web service interactions since Web services have no standard notion of session-oriented interactions. Other efforts provide similar security capabilities to Web services, such as the Liberty Alliance specifications (http://www.projectliberty.org).
7.2.1.3. EJB Tier Authentication
The EJB container has the ability to handle authentication. When a client directly interacts with a Web service endpoint implemented by an enterprise bean, the EJB container establishes the authentication with the client. Optionally, you can structure an application so that a Web container component may handle authentication for an EJB component. Several use case scenarios describe these situations.
One common scenario involves a Web tier component that receives a user request sent to it over HTTP. To handle the request, the Web component calls an enterprise bean component on the EJB tier, a typical scenario since many Web applications use enterprise beans. This is often done in browser-based Web applications and also with Web services applications that have a JAX-RPC Web endpoint. In these cases, the application developer places a Web component in front of the enterprise bean and lets the Web component handle the authentication. Thus, the Web container vouches for the identity of those clients who want to access enterprise beans, and these clients access the beans via protected Web components. Figure 7.3 illustrates how an application can be structured to use the Web container to enforce protection domain boundaries for Web components, and, by extension, for the enterprise beans called by the Web components.
Another use case scenario involves sending a SOAP request to an EJB service endpoint. Since the caller is making the SOAP request over HTTP, the Web service authentication model handles authentication using similar mechanisms—basic authentication and mutual SSL—to the Web tier component use case. However, rather than use a Web component in front of the EJB component, the EJB container directly handles the authentication. Note that in the J2EE platform, both Web and EJB tier endpoints support the same mechanisms for Web service authenication.
A third use case entails calls made directly to an enterprise bean using RMI-IIOP. This scenario is not common for Web services since they are not accessed with RMI-IIOP. However, some Web service endpoints, while processing a request, may need to access a remote enterprise bean component using RMI-IIOP. The Common Secure Interoperability (CSIv2) specification, which is an Object Management Group (OMG) standard supported by the J2EE platform, defines a protocol for secure RMI-IIOP invocations. Using the CSIv2-defined Security Attribute Service, client authentication is enforced just above the transport layer. The Security Attribute Service also permits identity assertion, which is an impersonation mechanism, so that an intermediate component can use an identity other than its own.
7.2.1.4. Enterprise Information System Tier Authentication
Many application components and Web service endpoints need to access enterprise information systems, such as databases or JMS resources. J2EE components get access to the connections of these resources through a resource manager connection factory. For example, the javax.sql.DataSource interface provides a resource manager factory interface to obtain a javax.sql.Connection for a database. JMS, JavaMail, and URL connection factories are also available for these common types of resources.
When integrating with enterprise information systems, J2EE components may use different security mechanisms and operate in different protection domains than the resources they access. In these cases, you can configure the calling container to manage for the calling component the authentication to the resource, a form of authentication called container-managed resource manager sign-on. The J2EE architecture also recognizes that some components need to directly manage the specification of caller identity and the production of a suitable authenticator. For these applications, the J2EE architecture provides a means for an application component to engage in what is called application-managed resource manager sign-on. Use application-managed resource manager sign-on when the ability to manipulate the authentication details is fundamental to the component's functionality.
The resource-ref elements of a component's deployment descriptor declare the resources used by the component. The value of the res-auth subelement declares whether sign-on to the resource is managed by the container or the application. With application-managed resource manager sign-on, it is possible for components that programmatically manage resource sign-on to use the EJBContext.getCallerPrincipal or HttpServletRequest.getUserPrincipal methods to obtain the identity of their caller. A component can map the identity of its caller to a new identity or authentication secret as required by the target enterprise information system. With container-managed resource manager sign-on, the container performs principal mapping on behalf of the component.
Care should be taken to ensure that access to any component with a capability to sign-on to another resource is secured by appropriate authorization rules. Otherwise, that component can be misused to gain unauthorized access to the resource.
The J2EE Connector architecture offers a standard API for application-managed resource manager sign-on. This API ensures portability of components that authenticate with enterprise information systems.
7.2.2. Authorization
Authorization mechanisms limit interactions with resources to collections of users or systems for the purpose of enforcing integrity, confidentiality, or availability constraints. Such mechanisms allow only authentic caller identities to access components. Since the J2EE application programming model focuses on permissions, which indicate who can do what function, authentication and identity establishment occur before authorization decisions are enforced.
After successful authentication, a credential is made available to the called component. The credential contains information describing the caller through its identity attributes. Anonymous callers are represented by a special credential. These attributes uniquely identify the caller in the context of the authority that issued the credential. Depending on the type of credential, it may contain other attributes that define shared authorization properties (such as group memberships), which distinguish collections of related credentials. The identity attributes and shared authorization attributes in the credential are collectively represented as security attributes. Comparing the security attributes of the credential associated with a component invocation with those required to access the called component determines access to the called component.
In the J2EE architecture, a container serves as an authorization boundary between the components it hosts and their callers. The authorization boundary exists inside the container's authentication boundary so that authorization is considered in the context of successful authentication. For inbound calls, the container compares security attributes from the credential associated with a component invocation to the access control rules for the target component. If the rules are satisfied, the container allows the call; otherwise, it rejects the call.
7.2.2.1. Declarative Authorization
Deployment establishes the container-enforced access control rules associated with a J2EE application. Generally, a deployment tool maps an application permission model, which is defined in the deployment descriptor, to policy and mechanisms specific to the operational environment.
The deployment descriptor defines logical privileges called security roles and associates them with components. Security roles are ultimately granted permission to access components. At deployment, the security roles are mapped to identities in the operational environment to establish the capabilities of users in the runtime environment. Callers authenticated by the container as one of these identities are assigned the privilege represented by the role.
The EJB container grants permission to access a method only to callers that have at least one of the privileges associated with the method. The Web container enforces authorization requirements similar to those for an EJB container. Security constraints with associated roles also protect Web resource collections, that is, a URL pattern and an associated HTTP method, such as GET or POST.
Although deployment descriptors define authorization constraints for an application, security mechanisms often require more refinement plus careful mapping to mechanisms in the operational environment in which the application is ultimately deployed. Both the EJB and Web tiers define access control policy at deployment, rather than during application development. The access control policy can be stated in the deployment descriptors, and the policy is often adjusted at deployment to suit the operational environment.
It is also possible during deployment to refine the privileges required to access components. At the same time, you can define the correspondence between the security attributes presented by callers and the container privileges. The mapping from security attributes to container privileges is kept to the scope of the application. Thus, the mapping applied to the components of one application may be different from that of another application.
A client interacts with resources hosted in a Web or EJB container. These resources may be protected or unprotected. Protected resources have authorization rules defined in deployment descriptors that restrict access to some subset of non-anonymous identities. To access protected resources, clients must present non-anonymous credentials to enable their identities to be evaluated against the resource authorization policy.
You control access to Web resources by properly defining their access elements in the deployment descriptor. For accessing enterprise beans, you define method permissions on individual bean methods. See “Handling Authorization” on page 320.
7.2.2.2. Programmatic Authorization
A J2EE container decides access control before dispatching method calls to a component. In addition to these container pre-dispatch access control decisions, a developer might need to include some additional application logic for access control decisions. This logic may be based on the state of the component, the parameters of the invocation, or some other information. A component can use two methods, EJBContext.isCallerInRole (for use by enterprise bean code) and HttpServletRequest.isUserInRole (for use by Web components), to perform additional access control within the component code.
To use these functions, a component must specify in the deployment descriptor the complete set of distinct roleName values used in all calls. These declarations appear in the deployment descriptor as security-role-ref elements. Each security-role-ref element links a privilege name embedded in the application as a roleName to a security role. Ultimately, deployment establishes the link between the privilege names embedded in the application and the security roles defined in the deployment descriptor. The link between privilege names and security roles may differ for components in the same application.
Additionally, a component might want to use the identity of the caller to make decisions about access control. As noted, a component can use the methods EJBContext.getCallerPrincipal and HttpServletRequest.getUserPrincipal to obtain the calling principle. Note that containers from different vendors may represent the returned principal differently. If portability is a priority, then care should be taken when code is embedded with a dependence on a principle.
7.2.3. Confidentiality and Integrity
Confidentiality mechanisms ensure private communication between entities by encrypting the message content so that a third party cannot read it. Integrity mechanisms ensure that another party cannot tamper with communication between entities; in particular, that a third party cannot intercept and modify communications. Integrity mechanisms can also ensure that messages are used only once. Attaching a message signature to a message ensures that a particular person is responsible for the content: In addition, the modification of the message by anyone other than the creator of the content is detectable by the receiver.
Configuring the containers to apply confidentiality and integrity mechanisms is done when an application is deployed into its operational environment. Components that need to be protected are noted as such. The corresponding containers can be configured to employ the required confidentiality and integrity mechanisms when interactions with these components occur over open or unprotected networks. Containers can also be configured to reject call requests or responses with message content that should be protected but is not.
The J2EE platform requires that containers support transport layer integrity and confidentiality mechanisms based on SSL so that security properties applied to communications are established as a side effect of creating a connection. SSL can be specified as requirements for Web components and EJB components, including Web service endpoints.
The deployment descriptor conveys information to identify those components with method calls whose parameters or return values should be protected. Details about interacting with a J2EE component using SSL are discussed in the next section. When a component's interactions with an external resource include sensitive information, these sensitivities should be described in the description subelement of the corresponding resource-ref. These elements make sensitive information available when security requirements are set at deployment.