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.
Rob's Blog - Technology, Atlanta, Startups and Stuff 
I find JAAS to be a bit confusing and over-architected for simple username/password authentication. I always like to know how the authentication I’m using works, and I can’t seem to figure it out with JAAS and end up doing my own. I just need to find a simple JDBC-username/password example and maybe I’d be a convert.
A lot of the perceived complexity depends on the app server. At its simplest level, JBoss provides a mechanism that requires 2 files, users.properties and roles.properties. users.properties manages the authentication part, roles.properties handles authorization. If you want simple, just create a single role, make all your users a part of that role, and restrict your apps to say that users must be a member of that role. Hopefully other app servers have a base level implementation that is just as simple, and more advanced implementations (LDAP,JDBC) for those who need it.
I found JAAS to useless for security of a web application. You access something you aren’t supposed to, and ‘pow’ you get an exception. Not a great user experience. It is as much work putting in a decent interface to handle the exceptions, as to do the security in the first place. Getting the initial set of security permissions for basic functionality is also a headache. I tied this path twice, once with Tomcat and once with Websphere. I didn’t think it handled the project’s needs either time I tried it. We had another group go down that road and also come to the same conclusion.
By ‘exception’, I’d presume you mean a 403 – forbidden error, at least that’s what a container ought to do. If so, you can solve the user experience issue my adding an “error-page” entry to your web.xml file, pointing them to a friendlier error page.
If the container’s giving you a full-on exception, Struts has declarative error handling that work nicely.
Of course, the core of the problem is that your app shouldn’t have links that encourage users to link to areas they’re not authorized to view – if they are presented with such links, THAT is the core design issue, not JAAS.