Hi Eddie, Thanks a lot for such an enlightening explanation.
-----Original Message----- From: Eddie Bush [mailto:[EMAIL PROTECTED] Sent: Saturday, May 28, 2005 10:01 PM To: Struts Users Mailing List Subject: Re: Security in Struts Tarek, Java provides a standard mechanism for you to tell if the person accessing your application has a certain permission. This is available through request.isUserInRole(String). Unfortunately, that only works for Container-Managed Authentication (CMA). You can make it work without using CMA, but it takes a little (not too much) work. Firstly, a Filter instance that is mapped to all your actions (and JSPs if you access them directly and they need security). This filter is really simple - if the user isn't authenticated, it sends them to the login page. If they are authenticated, the filter lets them pass through. There is one additional responsibility that I'll address later. Your login process authenticates your users and puts a bean out in the session to indicate the person is logged in - which is how your Filter knows they are logged in. I would recommend to you that the class for this bean implement java.security.Principal, since you can then use request.getUserPrincipal() to retrieve your bean (caveat later). Your login process will, additionally, determine the permissions that the person logging in has and make those available somehow in the session (my user bean actually stores these). Now, the caveat I spoke of: To make request.getUserPrincipal() and request.isUserInRole(String) work, you're going to have to write an HttpServletRequestWrapper implementation. This is very straight-forward and shouldn't take long. What you do here is to implement getUserPrincipal() to return the user bean after having retrieved it from the session - under the key you bound it to in your login process. Piece of cake! You'll also overload isUserInRole(String) to retrieve the users roles and determine if the passed-in parameter is in their list of roles. Again - piece of cake! Your Filter's additional responsibility: Before calling doChain(request, response), you'll want to wrap the request with an instance of your request wrapper. This is the trick (aka Magic!) that makes your application able to use standard methods available on the request. It sounds kind of cumbersome - complex, even - but once you start down the road, you'll soon see that it isn't much work at all. You *might* spend a day on all of this - two or three if you're totally unfamiliar with everything I've spoken about and have to do some research. This is - far and above - the best approach, but there's actually one better, if you can use it: http://securityfilter.sourceforge.net Essentially, the security filter project does what I just said you needed to do, but it doesn't provide database access to all RDBMS yet. Depending on how closely you want to simulate CMA and depending on if they have an adapter for your RDBMS, you might be better off implementing what I spoke of above yourself. For me, I wanted to see what role a person had inside of an action. It was easier for me to grow my own than write an adapter and have to learn how to use SecurityFilter. That may not be the case for you. Hope that helps! Eddie Bush ----- Original Message ----- From: "tarek.nabil" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <user@struts.apache.org> Sent: Wednesday, May 25, 2005 5:12 AM Subject: Security in Struts Hi everyone, We're building a project using Struts and are about to start on the security module. The requirements are that security should be fine grained, which means that it can not be on the module level, but rather on the JSP or Action level. Actually, the users might ask for security on the button level, but we intend to push back on that one. Are there any widely used approaches or best practices that we can follow? Note that we will not be using J2EE based authentication and security, which means we have a custom login process. Any suggestions are appreciated. Thanks --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 0521-4, 05/27/2005 Tested on: 5/28/2005 1:00:50 PM avast! - copyright (c) 2000-2004 ALWIL Software. http://www.avast.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
