See comments below
Regards,
Nic
----- Original Message -----
From: "Oleg V Alexeev" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, July 27, 2001 8:13 PM
Subject: Re: Role-based security
> Hello Nic,
>
> Hm... Nic, I think that 'roles' attribute in ActionMapping is not
> solution - it helps to check path based security. So we have container
> security and struts security on one way - is it right? And more - one
> of the hard errors in J2EE projects is custom security mechanism
> (sorry, I forget URL to resource... :( )
>
As I said in the posting, I believe this is what was asked for (actions
protected by being in a particular role). The TODO list says
"Add the ability to require the current user to be in a particular security
role before they can execute a particular action"
if this is wrong let me know and I will review it.
Any struts security will never be a replacement for a proper security
architecture, and the facilites provided by J2EE are relatively basic for
providing proper security. We do, however, have to work within these
constraints if we wish struts to have some security available to all
environments on which it will be run and not rely on container specific
features. This is not a replacement for the J2EE security nor is it a
replacement for a serious evaluation of the security architecture on
projects where this is paramount; but for a start for those people who
aren't interested in industrial strength security it provides something for
them to use. Having recently discussed security with BEA their suggestion is
not to use their own security features in WLS if you want a truly secure
site but to buy in third party support. If they can't get it right with the
clout they have, we are unlikely to either.
> But more generally, your approach is interesting, I like it. If we
> must check access level for the function, not path, then it is good
> solution. I think every developer in struts community some day take a
> look to the security problem in his application - and your solution
> can be standart way to solve it.
>
ASIDE: As a matter of interest, the 'solution' does not specify how the
roles get set and this is something we should address and I think (having
looked a little ahead in my mail box ;) that Ted alludes to this.
We still have path security provided by the J2EE declarative security this
is in addition to it as I understand it.
> P.S. I want to add SecurityService on base of your solution to the
> Services for my ServiceManager. Can I do so?
>
Is this the outcome of the Services thread that was going on here for a
while, or something different? Either way, feel free!
Let me know if I can help at all and thanks for your comments.
> Friday, July 27, 2001, 7:14:57 PM, you wrote:
>
> NH> Well the ideas for security solidified themselves first - so here is
my first attempt - any comments welcome!
>
> NH> I have included in the zip the files I have changed to implement role
based security in struts as it stands. There is not a lot in fact.
>
> NH> The basis is as follows. I have extended the struts-config.dtd to add
a 'roles' attribute to the 'action' element which can hold a comma separated
list of principals (either users or groups) to
> NH> be checked for each action. The ActionMapping has been extended to add
the getters and setters for this attribute. The ActionServlet has an extra
call in the processMapping method (if I remember
> NH> correctly) to call the security check which throws a
GeneralSecurityException if there is a problem, which is detected and
appropriate action taken (more on this later). I have added two classes.
> NH> ActionSecurity and ActionSecurityFactory. The ActionSecurity
implements the check on the user principal and their roles. It is created by
the factory class which picks up the class from the
> NH> web.xml (via the ActionServlet) which it should instantiate to do the
checks. By default this is the ActionSecurity class. This provides two
methods checkSecurityRoles which does the main work of
> NH> checking against getUserPrinicipal and isUserInRole; and mapRoles
which can be overridden if necessary. At the moment roles defined in the
struts-config.xml must match the principals and groups
> NH> specific to the app server you are running on rather than the security
roles (which may be different) that can be defined in the deployment
descriptors for declarative security. This is the
> NH> default behaviour. If it is possible to discover these mappings in the
app server you are using you can create a subclass of ActionSecurity and
override the mapRoles method to map between the
> NH> actual roles and the declared roles. I doubt this is possible in many
app servers but have included the hook for the sake of completeness. If you
create a subclass define a parameter in the
> NH> web.xml called securityFactory with the full package scoped classname
of the new class. Et voila!
>
> NH> But what happens when the user is found to not be in the correct role?
At the moment the user just gets a page not found at the browser level which
is good in one way in that if a user went to
> NH> the URL directly they wouldn't know if the URL is correct or not but
we may want it to go to a specific (configurable) 'illegal access' page or
something similar. Comments?
>
> NH> I don't know what other ideas people had for this piece so let me know
if this is not the sort of thing you were expecting and I'll see what I can
do!
>
> NH> Regards,
>
> NH> Nic
>
> NH> PS. Future (easy) extensions may be allowed roles and disallowed roles
etc. Let me know...
>
>
>
> --
> Best regards,
> Oleg mailto:[EMAIL PROTECTED]
>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
