Security in J2EE

The J2EE specification takes a pragmatic approach to security by focusing primarily on authorization within the J2EE environment and integration with security features that already exist in the enterprise.

You have already seen the J2EE design philosophy of separating roles with the development lifecycle identifying code developers, application assemblers, deployers, and administrators. The J2EE security supports this role-based model by using two forms of security:

• Declarative security is defined within the application's deployment descriptor (DD) and authorizes access to J2EE components, such as Web pages, servlets, EJBs, and so on. End user tools, such as the J2EE RI deploytool, support declarative security.

• Programmatic security is used when declarative security is not sufficient to meet the needs of an application. Security-aware components implement the security requirements by using programming constructs.

The J2EE security specification also requires transparent propagation of security credentials between components. In layman's terms, this means that once clients have logged in to a Web page, they do not need to authenticate themselves again for any EJBs accessed from the Web page. This means the authenticated identity of the user remains the same for all components (Web pages, servlets, client applications, and EJBs).

The J2EE security domain uses a standard terminology for the specification of the requirements. The terms are principal, role, and role reference, and each is discussed in the following sections.

Principals

Principals represent authenticated entities, such as users. The authentication mechanism is not defined within the J2EE specification, allowing existing authentication schemes to be integrated with a J2EE application.

The downside of not defining how users are authenticated means that some parts of the J2EE security features vary between one manufacturer's implementation and another. As the J2EE specification has evolved, additional security requirements have been incorporated to reduce the variation between implementations.

In a simple implementation, a J2EE principal is a user and the principal's name is the username. However, there is no requirement for a particular implementation to map the real usernames onto unique principal names. In fact, a principal can represent a group of users rather than an individual user. Using principals to implement security requires coordination between the developer and the deployer and can restrict the reusability of a particular J2EE component.

Wherever possible, J2EE security should be based on roles rather than principals because roles are more portable.

Roles

Roles are identified by the developer and represent how components in an application will be used. Typically, a developer will identify roles, such as user, administrator, manager, and so on, and suggest how the functionality in the application will be used by each identified role.

A deployer will map principals (real users and groups of users) onto one or more roles defined in the application. The deployer has total control over how the actual security authentication is mapped onto the J2EE application.

An assembler will combine the roles from many different components to map the security requirements from different components.

To reduce the coupling between the role names used by a developer and the actual role names available to the assembler, the J2EE components uses role references.

Role References

Role references define role names in a J2EE component's deployment descriptor. The developer defines the role reference, and the assembler or deployer maps the references onto an actual role in the target environment.

The relationships between principals, role references, and roles are shown in Figure 15.3.

In order to apply security to the Agency case study you will need to define users in the J2EE RI security domain as described in the next section.