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