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