An OnJava Article points out the advantages of J2EE’s security as compared to .NET. What I’ve found, though, is that most J2EE developers are completely ignorant of this security, and end up building their own, putting in ten times the effort to get half the functionality.
If your app server provides decent support for JAAS, you can plug in a variety of security providers, validating passwords and extracting roles from flat files, LDAP, a relational database, and more. The advantage here is that your mechanism for getting passwords and roles is fully decoupled from your applications, can be shared by multiple applications, and is already written for you.
On the web application side of things, you can declare the security configuration in your web.xml – you can specify login pages, login failure pages, which pages to secure, which to omit. Frankly, the declaration of which pages to secure is a bit lacking, when compared to ANT’s include/exclude functionality, but it’s worth the intrusion to get all this functionality for free. Your EJBs can also be secured declaratively. That’s not going to address every situation, so you can add some programmatic security on top of that. The current user and their ability to perform certain roles are built into the HttpServletRequest object, and so you can easily further lock down functionality that way.
For as much work as vendors have done to implement this, time and again I see developers failing to use it. Most of the time it is failure to understand what is available to them. The rest of the time, reasons are created why J2EE Container Managed Security is inadequate. While there are certainly occasions where this is true, I believe that most of the time, the core needs could be met using the built-in security. The biggest deficiency I see is that there’s no way to add additional metadata to your authentication. You can provide a user credential, and an authentication credential (password, certificate, etc), but that’s it. What if you wanted to run multiple companies off of a single security repository? You’d want usernames to only be unique per company, but possibly otherwise duplicated. Or what if you wanted to provide 2 security credentials, such as a password and a challenge/response code? As it stands, the JAAS interfaces have no place to put this data, so there’s not even an option to build extensions to manage it without gutting your app server. This is something that should be remedied ASAP as a part of the JAAS spec.
Other than that gripe, I can’t urge you strongly enough to investigate the best J2EE feature that you’re probably not using.