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... :( )
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.
P.S. I want to add SecurityService on base of your solution to the
Services for my ServiceManager. Can I do so?
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]
