Just an comment based on personal experience.
I've seen a number of Do-it-Yourself security systems in
Java webapps over the years. They pretty much all stink. At best, they make life difficult for maintenance people, since they have to be manually coded into what should properly be display and business logic. Failing to do so properly even once opens up your system to exploitation.
At worst, you end up with something that requires major application changes if the security system changes, almost never works in a single-signon environment (especially portals and portlets), carries several other liabilities that I could enumerate, and almost always has some fatal security hole at its core.
I am this very day, in fact attempting to mitigate the damage that came from people designing such a system, having just spent 6 weeks berating another group for the weaknesses in theirs.
The
J2EE builtin security isn't a cure for everything, but it can handle just about every situation I've seen in common use. Because it acts as a wrap-around gatekeeper, you can debug the app without having to debug the security at the same time. Because it surrounds the app, it guards the entrances to all functions, not just the ones you remember to guard. Because it's primarily declarative, "logic" errors are greatly reduced, since it's much easier to automate the vetting process.
J2EE container-based security is a standard. So when you want to sell your app as a third-party-product, you don't have to worry about whether it's going to fit well in someone else's environment. Because the realms are part of the container environment, the administration and integration are simpler. Because it's pluggable, you can use your own security environment (such as a tomcat-users.xml file) for
testing and be assured that the same app will work unmodified in your Active-Directory authenticated production system. Because it's a standard, new people on the team don't have to learn it - it's already in their books.
Also, the hooks for J2EE security are built into many common products, including Struts, some of the JSF packages, etc. You don't have to ugly-up your pages in order to limit the content of pages based on security requirements.
The most compelling reason of all, however, is the difference between "clever" people and people for whom paranoia is a full-time paying job. The J2EE standards were designed by groups of people whose main task was to look full time for possible exploits and head them off while providing maximum functionality, not ram something in while their main task was getting an app out the door, or even a committee of people who think they can do a better job but have never had formal training in mathematical proofs of security.
JSF is one of the more challenging environments for J2EE container security thanks to the funny URLs, but it can be done - I've put a number of such systems into production over the last 3-4 years and never once felt the need to forgo container-based security over a roll-my-own system.
Spring is popular these days because it does for application logic what J2EE Container-Based Security does for authentication and authorization. Both allow you to reduce the dependency of your application code on direct dependence on the services that they wrap, and in the process, reduce coding. Which boosts productivity and reliability.