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]
