| CONTENTS | PREV | NEXT | INDEX | J2EE BluePrints |
In distributed component computing, authentication is the mechanism by which callers and service providers prove to one another that they are acting on behalf of specific users or systems. When the proof is bidirectional, we refer to it as mutual authentication. Authentication establishes the call identities and proves that the participants are authentic instances of these identities. An entity that participates in a call without establishing and/or proving an identity (that is, anonymously), is called unauthenticated.
When calls are made from a client program being run by a user, the caller identity is likely to be that of the user. When the caller is an application component acting as an intermediary in a call chain originating with some user, the identity may be associated with that of the user, in which case the component would be impersonating the user. Alternatively, one application component may call another with an identity of its own and unrelated to that of its caller.
Authentication is often achieved in two phases. First, service-independent authentication requiring knowledge of some secret is performed to establish an authentication context that encapsulates the identity and is able to fabricate authenticators (proofs of identity). Then, the authentication context is used to authenticate with other (called or calling) entities. Controlling access to the authentication context, and thus the ability to authenticate as the associated identity, becomes the basis of authentication. Among the possible policies and mechanisms for controlling access to an authentication context are:
- Once the user performs an initial authentication, the processes the user starts inherit access to the authentication context.
- When a component is authenticated, access to the authentication context may be available to other related or trusted components, such as those that are part of the same application.
- When a component is expected to impersonate its caller, the caller may delegate its authentication context to the called component.
Some entities may communicate without requiring authentication. A protection domain is 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 9.1 illustrates that authentication is only required for interactions that cross the boundary of a protection domain. When a component interacts with components in the same protection domain, no constraint is placed on the identity that it can associate with its call. The caller may propagate the caller's identity, or choose an identity based on knowledge of authorization constraints imposed by the called component, since the caller's ability to claim an identity is based on trust, not authentication. If the concept of protection domains is employed to avoid the need for authentication, there must be a means to establish the boundaries of protection domains, so that trust in unproven identities does not cross these boundaries. Entities that are universally trusting of all other entities should not be trusted as a member of any protection domain.
In the J2EE architecture, a container provides an authentication boundary between external callers and the components it hosts. The boundaries of protection domains don't always align with those of containers. Containers enforce the boundaries, and implementations are likely to support protection domains that span containers. However, a container is not required to host components from different protection domains, although an implementation may choose to do so.
For inbound calls, it is the container's responsibility to make an authentic representation of the caller identity available to the component in the form of a credential. An X.509 certificate and a Kerberos service ticket are examples of credentials. A passport or a driver's licence are analogous artifacts used in person-to-person interactions.
For outbound calls, the container is responsible for establishing the identity of the calling component. In general, it is the job of the container to provide bidirectional authentication functionality to enforce the protection domain boundaries of the deployed applications.
Without proof of component identity, the interacting containers must determine if there is sufficient inter-container trust to accept the container-provided representations of component identity. In some environments, trust may simply be presumed, in others it may be more explicitly evaluated based on inter-container authentication and possibly the comparison of container identities to lists of trusted identities. If a required proof of identity is not provided, and in the absence of a sufficient inter-container trust relationship, a container should reject or abandon a call.
Figure 9.2 illustrates these authentication concepts in two scenarios: an authenticated user scenario and an unauthenticated user scenario.
The authenticated user invokes a calling component that employs the user's authentication context to prove its identity to an intermediate component. When the called component makes a call it propagates the identity of its caller. The propagated identity is unproven, and so will be accepted only if the targets trust the caller, that is, if they reside in the same protection domain. The figure also differentiates identity propagation from delegation and subsequent impersonation. In propagation, the service providers bear the burden of determining whether they should accept propagated identities as authentic. In delegation, the user provides the called component with access to its authentication context, enabling the called component to impersonate the user in subsequent calls. Impersonation requires the user to trust the impersonator to act in its behalf. The lower portion of the figure depicts the propagation of an unauthenticated user identity in the form of an anonymous credential. An anonymous credential is the one form of unproven identity that may be propagated independent of trust.
In a typical J2EE application, a user would go through a client container to interact with enterprise resources in the Web or EJB tiers. Resources available to the user may be protected or unprotected. Protected resources are distinguished by the presence of authorization rules (see Section 9.3) that restrict access to some subset of non-anonymous identities. To access a protected resource, a user must present a non-anonymous credential such that its identity can be evaluated against the resource authorization policy. In the absence of a trust relationship between the client and resource containers, the credential must be accompanied by an authenticator that confirms its validity. This section describes the various authentication mechanisms supported by the J2EE platform and how to configure them.
9.2.2.1 Web Tier Authentication
An Application Component Provider can designate that a collection of Web resources (Web components, HTML documents, image files, compressed archives, and so on) is protected by specifying an authorization constraint (described in Section 9.3.7.1) for the collection. When an anonymous user tries to access a protected Web resource, the Web container will prompt the user for a password to authenticate with the Web container. The request will not be accepted by the Web container until the user identity has been proven to the Web container and shown to be one of the identities granted permission to access the resource. Caller authentication performed on the first access to a protected resource is called lazy authentication.
When a user tries to access a protected Web-tier resource, the Web container activates the authentication mechanism defined in the application's deployment descriptor. J2EE Web containers must support three authentication mechanisms: HTTP basic authentication, form-based authentication, and HTTPS mutual authentication, and are encouraged to support HTTP digest authentication.
In basic authentication, the Web server authenticates a principal using the user name and password obtained from the Web client. In digest authentication a Web client authenticates to a Web server by sending the server a message digest along its HTTP request message. The digest is computed by employing a one-way hash algorithm to a concatenation of the HTTP request message and the client's password. The digest is typically much smaller than the HTTP request, and doesn't contain the password.
Form-based authentication lets developers customize the authentication user interface presented by an HTTP browser. Like HTTP basic authentication, form-based authentication is not secure, since the content of the user dialog is sent as plain text, and the target server is not authenticated.
In single-signon environments, discretion must be exercised in customizing an application's authentication interface. It may be preferable to provide a single enterprise-wide custom user authentication interface, rather than implementing a set of application-specific interfaces.
With mutual authentication, the client and server use X.509 certificates to establish their identity. Mutual authentication occurs over a channel protected by SSL. Hybrid mechanisms featuring either HTTP basic authentication, form-based authentication, or HTTP digest authentication over SSL are also supported.
An authentication mechanism is configured using the login-config
element of the Web component deployment descriptor. Code
Example 9.1, Code Example 9.2, and
Code Example 9.3 illustrate the declaration
of each type of authentication mechanism.
<web-app> <login-config> <auth-method>BASIC|DIGEST</auth-method> <realm-name>jpets</realm-name> </login-config> </web-app>
| Code Example 9.1 HTTP Basic and Digest Authentication Configuration |
<web-app> <login-config> <auth-method>FORM</auth-method> <form-login-config> <form-login-page>login.jsp</form-login-page> <form-error-page>error.jsp</form-error-page> </form-login-config> </login-config> </web-app>
| Code Example 9.2 Form-Based Authentication Configuration |
<web-app> <login-config> <auth-method>CLIENT-CERT</auth-method> </login-config> </web-app>
| Code Example 9.3 Client Certificate Authentication Configuration |
In both HTTP basic and form-based authentication, passwords are not protected
for confidentiality. This vulnerability can be overcome by running these authentication
protocols over an SSL-protected session, which ensures that all message content,
including the client authenticators, are protected for confidentiality. Code
Example 9.4 demonstrates how to configure HTTP basic authentication over
SSL using the transport-guarantee element. Form-based authentication
over SSL is configured in the same way.
<web-app> <security-constraint> ... <user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint> </security-constraint> </web-app>
| Code Example 9.4 SSL Hybrid Authentication Mechanism |
9.2.2.2 EJB Tier Authentication
The J2EE 1.2 platform specification doesn't require interoperable caller authentication at the EJB container. Also, network firewall technology may prevent direct Internet interaction (via RMI) between client containers and enterprise beans. One way that an EJB container can protect access to enterprise beans is to entrust the Web container to vouch for the identity of users accessing the beans via protected Web components. As illustrated in Figure 9.3, such configurations use the Web container to enforce protection domain boundaries for Web components and the enterprise beans that they call.
In a multitier, multicomponent application, certain call patterns should be avoided for security reasons. For example, an application that calls protected EJB resources from unprotected Web resources can run into problems, because the Web tier's lazy authentication paradigm doesn't require user authentication except when the user attempts to access a protected resource. While the protection requirement can be moved to the EJB tier, care must be taken to ensure that users who are capable of authenticating can do so. With lazy authentication, a user who wants to visit a protected EJB resource must have visited a protected Web resource. One way to ensure this would be to front every protected EJB resource with a protected Web resource. Another approach would be to link to a protected Web resource (perhaps appearing as an authenticate button) on every Web resource that calls EJB resources. This approach gives the user the option of authenticating (by visiting the protected Web resource linked behind the button) prior to accessing an EJB resource, especially after having been denied access by the EJB resource through an unprotected page.
When an application is deployed with a hybrid authentication mechanism, the Deployer must ensure that the transport-guarantee element of each protected Web resource is set to CONFIDENTIAL. Otherwise, the client authenticator won't be fully protected.
9.2.3.1 Enterprise Information System Tier Authentication
In 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, the calling container can be configured to manage the authentication to the resource for the calling component. This form of authentication is called container-managed resource manager signon. The J2EE architecture also recognizes that some components require an ability to manage the specification of caller identity, and the production of a suitable authenticator directly. For these applications, the J2EE architecture provides a means for an application component to engage in what is called application-managed resource manager signon. Application-managed resource manager signon is used when manipulating the authentication details is a fundamental aspect of the component's functionality.
The resource-ref elements of a component's deployment descriptor
(described in greater detail in Section
9.3) declares the resources used by the component. The subelement
res-auth specifies the type of signon authentication. Components
can use the EJBContext.getCallerPrincipal and HttpServletRequest.getUserPrincipal
methods to obtain the identity of their caller. The component may map the caller
identity to a new identity and/or authentication secret as required by the target
enterprise information system.
With container-managed resource manager signon, the container would perform the principal mapping on behalf of the calling component. Container-managed principal mapping isn't explicitly defined in any of the J2EE specifications. Whether it is performed by the container or embedded in the caller, the mapping of caller identity to an identity and authentication secret capable of accessing resources in the enterprise information system tier should be modeled as a protected resource, and secured by appropriate authorization rules (see Section 9.3.6).
The Connector architecture discussed in Section 6.10 offers a standard API for application-managed resource manager signon. The Connector provided API will ensure portability of components that authenticate with enterprise information systems.
Many e-commerce applications are designed to make it as easy as possible for a user to become a customer. In contrast to typical computer user authentication environments, where a user must wait for an administrator to set up the user's account, many e-commerce applications enable users to set up their own accounts without administrative intervention. Frequently the user is required to provide his or her identity and location, agree to some contractual obligations, provide credit card information for payment, and establish a password to protect the account.
Once the registration dialog is complete, the user can access the protected resources of the site. In the future, client certificates will replace the identity and password elements of the registration to improve the accountability of the authentication. This transition will also relieve users from the risks they assume when they reuse a single password with multiple vendors as their own form of single signon. Mechanisms to support auto-registration are not specified by the J2EE platform and are thus specific to the container implementation.
Web resources that provide the user interface for auto-registration must be protected. This is accomplished by setting the transport-guarantee of these resources to CONFIDENTIAL.
The Application Component Provider is responsible for declaring references made by each component to other J2EE components and to external resources. These declarations are made in the deployment descriptor. In addition to their role in locating services, such declarations serve to inform the Deployer of all the places in the application where authentication may be necessary. Enterprise bean references are declared using ejb-ref elements. Enterprise information system references are declared with resource-ref elements. In both cases, the declarations are made in the scope of the calling component, and the collection of declared references serves to expose the application's inter-component/resource call tree.