----- 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...
