I've been involved in quite a few web-based applications, and every time I've done one, the team has a different kind of application-level security.
I'm interested in people's thoughts on the following methods.
1. Using container-based authentication and authorization (in the form of j_security_check and the <security-constraint> sections of web.xml).
Here are the advantages I see for this:
- Declarative security restrictions. I think this is great! No matter what I decide to do, the fact that I can change the security restrictions using a file instead of code will be mandatory.
- Container supports the actual login procedure, so I don't have to write/manage the code.
Unfortunately, there are also some disadvantages, and some of them are deal-breakers:
- No logout function (does session.invalidate() kill it? it occurs to me that it doesn't, but I haven't yet tried)
- If you hit a resource that requires auth, you go to the login page, login, and then go to the page you were trying to hit. I need to be able to first send the request to an action that will set up the user's session before the "destination" resource is accessed. (deal-breaker)
- If I want to modify usernames or passwords as they are read by j_security_check, I cannot do this. A concrete example: often, it is preferable to have case-insensitive usernames and passwords. Using j_security_check, I cannot flatten-out the case before the authorization is done. (I suppose this might be solved using a custom Realm). (deal-breaker)
Given that container authorization has a few shortcomings, there are also two other obvious styles of AAA:
2. Do it myself using action-level code. Each action (in my case, struts, but it really doesn't matter) must perform its own check.
This burdon can be lessened by inserting a common superclass that can handle the checks, redirections to login, etc., but that would require me to re-code most of my existing actions because they either need to call an authorization method provided by the superclass or the superclass must implement a "final" version of the request handler method and then call an abstract method defined in the subclass. This seems cleaner yet requires more code changes.
On the upside, I have complete control over the login flow, and I get to keep the desired declarative security model. (Does anyone know if there's an easy way to grab the <security-constraint> stuff from the web.xml file, or would I have to parse it myself and keep my own data structure for this purpose?)
On the downside, I now have to write this code and maintain it. Also, the <security-constraint> and j_security_check conspire together to do really sexy things like cache POST data and send it ultimately to the desired resource. It would take me some time to clone that functionality.
3. Do it myself using a Filter. This has the same advantages and disadvantages as #2 up there, except that I wouldn't have to change any of my actions to support the security checks. I think I'd prefer this techniqu, but I have no experience writing filters. They should be pretty darned easy, right?
So, if anyone has some great words of wisdon, I'd love to hear them.
I'd also love to hear about any frameworks that I could add to my applications that would handle this stuff for me. Again, I'd rather re-use something than code it and maintain it myself.
I'm not trying to start a flame war about AAA, so feel free to email me directly if you don't want to clutter the list.
Thanks, -chris
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
