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— 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— 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. Also, the authenticated identity of the user remains the same for all components (Web pages, servlets, client applications, and EJBs).

J2EE Security Terminology

The J2EE security domain is based around the concept of principals, roles, and role references.

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 remove the variation between implementations. Future versions of the J2EE specification will add additional security-related constraints as the underlying technology matures and standardizes.

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. Principal names are only used in programmatic security and are inherently non-portable.

Wherever possible, J2EE security should be based on roles rather than principals because roles are more portable than principal names. Using principals to implement security requires coordination between the developer and the deployer and can restrict the reusability a particular J2EE component.

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 the roles defined in the application. The deployer has total control on how the actual security authentication is mapped onto the J2EE application.

An assembler will combine the roles from many different components to create roles that represent common security requirements across different components.

Role References

Role references are used to map the names used in programmatic security to the roles defined in the deployment descriptor (DD). The developer defines the coded role names used in the code, and the assembler or deployer maps the coded references onto the roles defined in the application.

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

Working with J2EE RI Security

So far, you have only been aware of J2EE RI security when running client applications. Even though your applications so far have not been security aware, the J2EE RI environment requires your code to be run inside an environment that has a security context.

Web applications run within the J2EE RI Web server that does have a security context. However, applications that run from the command line, such as those you developed on Day 4, “Introduction to EJBs,” and Day 5, “Session EJBs,” do not have a security context. You must add your client classes to the Enterprise Application Resource (EAR) file as a client application to obtain a security context. The runclient program is used to run your client applications with a security context.

Before you look at making your J2EE application security aware, you must spend a short time looking at the J2EE RI support for a simple authentication system.

The J2EE RI provides an authentication domain that can be used during application development. The RI security domain supports:

• Realms— A realm defines users that are authenticated using the same mechanism. The J2EE RI defines two realms:

  • default Consisting of users identified by passwords

  • certificate Consisting of users identified by X509 digital certificates, (certificates are only used to authenticate Web browser clients)

• Users— Defines a username within the J2EE security domain. In the default realm, the username is the principal name. In the certificate realm, the common name on the certificate is the username.

• Groups— Users in the default realm can be assigned to groups. Groups can be mapped onto role references to simplify security administration.

Adding Users and Groups

Users and groups can be added to the J2EE RI server via two tools:

• realmtool A command-line–based interface

• deploytool A GUI interface

Both tools provide limited support for adding users, groups, and certificates to the J2EE authentication domain. After changes have been made to the J2EE security realms, the server must be restarted before those changes take effect.

The command line realmtool supports the following options:

RealmTool
Options
 -show
 -list          realm-name
 -add           username password group[,group]
 -addGroup      group
 -import        certificate-file -alias alias
 -remove        realm-name username
 -removeGroup   group

The tool lacks the ability to list groups in the default realm, but it has the advantage of working without having to have the J2EE server up and running.

The GUI interface is more functional and easier to use and is accessed via the “Tools -> Server_Configuration” menu in deploytool. Figure 15.4 shows the main user configuration screen.

Although the GUI interface is easier to use, it requires the J2EE server to be running. The server must be stopped and restarted for the changes to be recognized by your applications.

Neither utility supports the ability to change a user's password. If a password is forgotten, the user must be deleted and re-created to define a new password.

The default users provided with the J2EE RI server are shown in Table 15.1.

Both utilities are intuitive to use. For today's work, you will need to add some sample users as defined in Table 15.2.

You will need to add the groups for applicant and customer as well as the users shown in Table 15.2. After making your changes, don't forget to stop and restart the J2EE server.