Authentication and Authorization

J2EE provides both declarative and programmatic support for authentication and authorization, analogous to its declarative and programmatic support for transaction management.

Authentication is the task of ascertaining a user's identity. Users present credentials to the server – most often, a password – to prove their identity. Authorization is the problem of determining what resources within the application a particular identity should be allowed to access.

J2EE integrates authentication and authorization across all architectural tiers and components. Typically, users will identify themselves to the application interface (for example, a web interface, or a Swing GUI). The J2EE server is responsible for propagating this identification to all application components that the user's actions cause to be invoked. This will be done by associating a user identity with a thread of execution.

The container's transparent management of authorization frees developers to devote more resources to implementing application functionality.

The Standard Security Infrastructure

J2EE security is role-based. Each user of a system can have a number of roles. Different access privileges can be associated with different roles.

Each synchronous call to a J2EE component carries the following security information, obtained through the component APIs:

• A java.security.Principal object. This can be used to find the authenticated username.

• Whether the user is in a particular role. This can be used for programmatic restriction of user permissions.

Important 

If the username obtained from the security principal is the primary key to the user's persistent data, the standard security infrastructure can be used to avoid the need to pass primary key parameters with method invocations for authenticated users. This is particularly helpful in the case of stateless session beans. This is a good example of how standard infrastructure provided by the server can be used to simplify the programming model.

Access to protected resources may be limited declaratively to users in certain roles. This is done in the web.xml and ejb-jar.xml deployment descriptors. It's up to the server how users are mapped onto these roles, as we'll see. The EJB specification (§21.2.4) recommends the use of declarative, rather than programmatic, security, "The Bean Provider should neither implement security mechanisms nor hard-code security policies in the enterprise beans' business methods".

If a user is forbidden access to a protected resource because of declarative restrictions, the result varies based on the type of request. A web request will be given a standard HTTP return code indicating unauthorized access, or a page defined by the web application for display in this event. A method invocation on an EJB will throw a java.rmi.RemoteException if the client is remote or a javax.ejb.EJBException if the client is local.

Web containers are most likely to process users' security credentials. The servlet specification requires J2EE-compliant web containers to support HTTP basic authentication and form-based authentication. Basic authentication is defined in the HTTP specification and authenticates a user in a realm (a security protection space) based on a username and password. Basic authentication is not secure and it's impossible to customize its appearance in the browser, so it shouldn't be used in enterprise applications.

Form-based authentication is much more useful, and the servlet specification describes a standard mechanism for managing it. A web container must implement a POST action with the distinguished pseudo-URL j_security_check, which takes username and password parameters with the defined names j_username and j_password. The container must implement the action to establish the user's identity and the roles. The login form submitted for invoking the security check action is part of the web application. This allows it to be given any desired branding. Servers should allow the login form to be submitted using HTTPS, to ensure that user credentials are not compromised in transport.

The container will force the user to authenticate by submitting the login form only when required (for example, when an unauthenticated user tries to access a protected resource). This is termed lazy authentication, and means that users who never attempt to access protected resources will never be forced to authenticate. Once authenticated, a user will not be challenged again within a session. The user identity will be carried through to calls to other components of the application. Thus there is no need for user code behind protected resources to check that authentication has occurred. It's also possible to change the set of resources that are protected – perhaps to reflect changing business rules – without modifying the underlying code.

The choice between basic and form authentication is made declaratively in the web application's deployment descriptor. There is no need to modify application code.

There is presently no similar standard approach to authenticating users of application clients (non-web remote GUIs using EJBs).

Important 

Both declarative and programmatic authorization techniques are simple to use. However, the declarative model is preferable, as it simplifies the programming model and enhances deployment flexibility.

The Server Implementation

Although it defines how a J2EE server should challenge users to enter their credentials and how it must propagate security identities with calls within an application, J2EE does not mandate how a server should implement authentication. For example, if a user presents a username and password to a web application when challenged as a result of requesting a restricted URL, how should the container determine whether the credentials are valid, and what roles the user is in? J2EE does not specify how user information should be stored, and how it should be checked.

There is also no standard API to make a user authenticated without submitting the application's login form – a problematic omission. We might need this functionality, for example, when we create a new user account. Obviously we don't want to make the user login using the username and password they just provided. We need to resort to proprietary server extensions to achieve this.

Authentication has traditionally been server-specific. Typically, each server will define a security management interface that must be implemented to perform custom authentication against a database, directory server or other store of user information. For example, WebLogic uses pluggable security realms that implement the weblogic.security.acl.BasicRealm interface.

It's important to ensure that custom security managers are efficient. The container may call them frequently to check user permissions; even after a user session has been established (WebLogic provides a caching realm to reduce the workload of any underlying security manager).

Unfortunately, custom security managers will not normally have access to components within user applications such as entity beans or JDOs exposing user data. This is because security checks are likely to be made at a server-wide level, rather than an application level (although this varies between application servers). So there is a potential problem of duplication of data access logic, and possibly the update of the underlying data store by the user manager and application components.

Refer carefully to your application server's documentation when addressing authentication requirements.

A potential standard alternative interface for checking supplied credentials is Java Authentication and Authorization API (JAAS), defined in the javax.security.auth package and sub-packages. JAAS provides for pluggable authentication and authorization implementation. How easy it is to integrate with a J2EE servei varies between servers. Please refer to the following resources for further information about JAAS:

• http://www.pramati.com/docstore/1270002/ Documentation from Pramati on integrating JAAS with a J2EE server.

• http://www.theserverside.com/resources/article.jsp?l=JAAS Article on integrating JAAS authentication with Struts or any other MVC web framework, which also contains many useful references.

• http://java.sun.com/products/jaas/ The JAAS home page.

• Security documentation with your application server.

Important 

The catch to using the standard J2EE security infrastructure is that it will probably be necessary to write custom code to check user credentials and establish user permissions. However, similar code would be necessary as part of any homegrown security system. Application servers provide documented interfaces for user management. These interfaces can be implemented for each application server an application is deployed on without affecting the application codebase, ensuring that the design remains portable. Application servers may also provide support (such as abstract superclasses for implementing custom user managers).

JAAS provides a newer, standard alternative for authentication, although custom configuration will still be required. Please refer to documentation with your server on how JAAS may be integrated with it.