Java Enterprise in a Nutshell, Third Edition

Limitations of J2EE Security

One important aspect of security is preventing unauthorized access, either inadvertent or intentional. For example, the application prevents a regular user from accessing a set of URLs that only an admin can access. As another example, the application must prevent a regular user from invoking a set of methods that only an admin can invoke. Declarative security helps achieve this goal.

Sometimes, prevention happens too late from a usability perspective. Ideally, the application should present users only the functionality that they can access. The functionality that they do not have access to should be hidden or disabled. Despite the advantages of declarative security, it can’t do checks at this level of granularity. Programmatic security can definitely help in this regard, especially with web contexts where specific visual or functional elements on web pages need to be enabled or disabled based on the identity and roles of the user.

For example, a common security feature is to allow users to edit their own data. The application allows the customer to edit his own order, and not somebody else’s order. Granular security checks like this need to occur programmatically in the code—declarative authorization measures in J2EE aren’t expressive enough to represent business logic at this level.

Other low-level gaps in the J2EE security landscape can also lead to custom programmatic measures. J2EE web components, for example, do not have a standard way to explicitly ...