----- Original Message -----
Sent: Friday, July 27, 2001 4:14 PM
Subject: Role-based security
Well the ideas for security solidified themselves
first - so here is my first attempt - any comments welcome!
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.
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 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 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. 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 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 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
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 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
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 web.xml called securityFactory with the
full package scoped classname of the new class. Et voila!
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 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?
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!
Regards,
Nic
PS. Future (easy) extensions may be allowed roles
and disallowed roles etc. Let me know...