Section 10.7. Limitations of J2EE Security

10.7. 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 codedeclarative 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 log out a user from a web application. The most common way programmers implement this feature is by invalidating the HTTP session in their code. However, this technique works consistently only for form-based logins since other authentication schemes can leave a persistent cookie on the client web browser. This limitation may be addressed in future versions of the servlet specification, but at the moment, it's a practical issue that forces developers into custom programming.

Sadly, once developers move down the path of programmatic security measures, they are inclined to abandon J2EE security altogether in favor of custom development. Rather than provision the application server to integrate with the organization's security stores, the pressures of deadlines and short-term product or service goals can lead to application-specific security solutions that can be expensive to maintain, confusing to users (in terms of login mechanics, authorization models, etc.), and potentially risky in terms of security holes created in distributed security implementation code.

Naturally, these inclinations should be resisted as much as possible. You should strive to create a consistent security model across your organization's applications and systems, rather than a patchwork of local, custom implementations. And where you have J2EE application servers in place, you should leverage their security services as much as is practical in your environment. If they can tie directly into your security stores (LDAP servers, Active Directory, and so on), you should attempt to establish this level of integration and stick to business logic in your application code.