Understanding Container-Managed Security

Container-managed security puts the onus on the Web server for enforcing and implementing security policies. This means developers don’t need to write code to use authentication and authorization (though they can if they want); they can rely on the servlet container to do the authentication for them.

By delegating authentication and authorization to the server, developers can write general-purpose code that can apply to many user roles. If they want to restrict access to this general-purpose code, they ask the administrator to implement container-managed security and place a security policy between the users and the resources. Therefore, this code can be protected from unauthorized access without any changes in the application. Further, the restriction can be altered without changing the application if need dictates it.

Let’s look at an example of what container-managed security provides for Web application developers and administrators. Imagine a Web application that enables employees in a company to view their performance reviews online. The application also enables supervisors to add reviews. This application must ensure the following:

• An employee is authenticated before seeing the confidential information.

• A supervisor is authenticated before seeing and adding employee records.

In a traditional Web application, the Web application developer would write the authentication routines and place them in the application’s logic. Once a user has been authenticated, they must also be authorized, which means more application-specific code to determine which sections of the applications a supervisor can access and which sections a worker can access. But suppose company policy changes and human resources now has responsibility for adding the performance reviews. You have to rewrite code to stop supervisors viewing reviews and to allow human resources to add reviews.

With container-managed security, the administrator handles this change. All the mappings of users to roles and roles to access rights are placed in server configuration files and as such aren’t hard-coded. When human resources is given access to the review-adding process, the administrator maps the new relationship in the configuration file, and the developers don’t need to do anything. Figure 11-2 shows this process.

Figure 11-2: (a) The manager can view and add reviews. (b) The human resources team can now view and add reviews, but the supervisor can’t.

In Figure 11-2 (a) the worker and the human resources team can only view the reviews because they’re mapped to the worker role. Managers can view and add reviews because they’re mapped to the supervisor role. In Figure 11-2 (b) members of the human resources team can now view and add reviews because they’re now mapped to the supervisor role. The supervisor is now mapped to the worker role and can only view the reviews. This shows how easy it is to reassign users to roles without changing an application’s logic. It’d be just as easy to change any of the other mappings.

Storing a Digested Password

If you’re worried about storing passwords in plain text (and you probably will be), then you can digest them with the digest utility that’s supplied with Tomcat, as described in Chapter 3. Navigate to CATALINA_HOME/bin at the command line, and run the following:

 > digest -a md5 admin 

This digests the password called admin using the MD5 algorithm. You’ll see the digested password as follows:

 admin:21232f297a57a5a743894a0e4a801fc3 

An alternative is to use the SHA algorithm, which is more secure.

 > digest -a sha admin  admin:d033e22ae348aeb5660fc2140aec35850c4da997 

You can then copy the section after the colon into the password field of your realm’s password store.