That being said, I have seen some questions floating around to the effect of "Why use ESAPI for authentication and access control when we already use *insert framework here*?"
This is a very valid question, and I think that some people may have gotten the wrong idea about what the ESAPI is really trying to accomplish.
There are some fantastic frameworks out there for logging, authentication, cryptography and all the things that the ESAPI does, and it is not the intention of the ESAPI to replace these frameworks, but rather to provide a central interface for developers to access the functionality of those frameworks in a simple fashion.
While we provide a reference implementation of ESAPI, a good deal of the code provided is to provide an example, or a plug and play environment for the ESAPI itself. It is not only intended but even reccomended that if you are using the ESAPI in a production application, that you use the pieces of the reference implementation that work for you, but also create wrapper objects to use your existing security controls through the ESAPI. This provides several things that are deeply important to having a secure application, especially in an agile environment.
- Provides a standard and central API for developers to access security controls which makes the job of the developer simpler. If the developer knows that anytime he needs to log a user in he should call ESAPI.authenticator().login( request, response ) it makes it easier to remember and easy to implement.
- Decouples the application from the security frameworks in use. This is probably the most important piece of the puzzle, at least in my mind. Things like access control checks, output encoding, and logging are sprinkled throughout the entire codebase of an application, which makes it a very painful process to migrate to a new framework if you ever need to. Imagine you have an application which consists of several hundred class files and and several hundred JSP files. One day you decide that you want to migrate from using Spring ACEGI to JAAS. You now have to change the code in every class file where you access that library to use the new library. If you were using the ESAPI, you would have a wrapper implementation of Authenticator and AccessController that delegated to your framework. Now you just have to write a new wrapper class and change a properties file and your job is done!
It has been said that ESAPI should be used to "fill in the gaps" where other security controls do not work, such as output and input encoding. I think that should be rephrased to reflect the Reference Implementation of the ESAPI and not the ESAPI itself.
That being said perhaps it would be helpful if there was an incubator project under the ESAPI umbrella that provided wrappers for the more popular frameworks. Having that could allow the developers have the ability to drop in the ESAPI then use wrapper jars as *plug-ins* to the API. So if you were using JAAS under the covers for your authentication and access control framework, you could drop in ESAPI.jar and ESAPI-JAAS.jar into your classpath, update your ESAPI.properties to use org.owasp.esapi.provider.authentication.JAASAuthenticator and you are off to the races.
What do you think?