You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Luca Fossato <fo...@pow2.com> on 2001/11/07 13:28:34 UTC

access control list features

Hi,

we use Struts for our projects, and so we would like to (try to) contribute
to this framework.
We developed an open source (Mozilla PL) access control list system,
inspired by the Turbine ACL idea (for the database schema. and for 'actors'
(java objects) like user, group, role, permission).
The package contains also tag libraries for jsp pages and two classes that
provide the 'Struts integration' (based on Struts 1.0 relase):

See http://sourceforge.net/projects/pow2acl

Unfortunately, the package lacks an overview documentation and direct code
examples...


I found that Mr. Nic Hobs already developed a Role-Based Actions system
(http://www.husted.com/struts/resources/struts-security.htm),
anyway I try to make a simple description of the acl system (I apologize for
my english ;^)

The acl uses user, group, role and permission entities data (persisted into
a relational database) to execute queries like:

- is user in a certain group ?
- is user in a certain role ?
- has user a certain permission ?
- has user in a given group a certain role ?
etc.

These queries are wrapped into the ACLDAO object, who uses JDBC to execute
the statements versus a fixed database schema.

The integration with Struts actions happens using the following classes:

ACLAction and ACLActionServlet.

ACLAction is an abstract class that extends Action and adds the
'validatePermission' hook method:

    /**
     *  Validate user permissions.
     *  <br>
     *  This is an hook method; this default implementation always returns
true.<br>
     *  Subclass this class and make your own implementation.
     *
     *  @param user   the current User object.
     *  @param acl    the data access object for ACL validation.
     *  @param errors the ActionError list to fill with possible errors.
     *  @return true if user has permissions for execute this action,
     *          false otherwise.
     */
    public boolean validatePermissions(User user, ACLDAO acl,
HttpServletRequest request, ActionErrors errors)
    {
        return true;
    }

it uses the User object and ACLDAO to check permissions, roles, etc.
ACLAction subclasses can override validatePermissions and provide the
'security' statements.
The method returs true or false.


ACLActionServlet extends ActionServlet;
ovverrides processActionPerform method, checking if the input action is an
instance of ACLAction (a subclass of).
If this is true, processActionPerform checks for valid user, then calls
ACLAction.validatePermissions method
(note that the default implementation returns always true).
If validatePermission returns false, ACLActionServlet do:

return mapping.findForward(ACLAction.ACL_FWD_NOPERMISSIONS);

else do

ActionForward forward = action.perform(mapping, formInstance, request,
response);
return (forward);


Into the view (the jsp pages), it is possible to use custom tags like:

<acl:hasUserPermission permission="DBAadmin" group="admin">
     <a href="deleteTable.jsp">|delete table|</a>
</acl:hasUserPermission>

or

<acl:isUserInRole role="admin">
   <a href="admin/index.jsp">admin store items</a>
</acl:isUserInRole>

or

<acl:isUserInRole role="projectmanager" redirect="login.do"/>

for template pages (you cannot use redirection into 'content' jsp pages)

etc.

There is also a database frontend web application to manage the acl tables
and a suite of Cactus tests for the tag library (and thus for the data
access).
The package is builded using also  pow2Toolkit (a 'common' repository of
classes) that has its own 'user' philosophy.
We should release pow2Toolkit  as open source soon... (the problem is
time...)

Hope it can be useful;

Luca








--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: access control list features

Posted by Ted Husted <hu...@apache.org>.
Thanks, Luca!

I've added this to my page, and will update the Struts Resource page in
due course.

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/



Luca Fossato wrote:
> 
> Hi,
> 
> we use Struts for our projects, and so we would like to (try to) contribute
> to this framework.
> We developed an open source (Mozilla PL) access control list system,
> inspired by the Turbine ACL idea (for the database schema. and for 'actors'
> (java objects) like user, group, role, permission).
> The package contains also tag libraries for jsp pages and two classes that
> provide the 'Struts integration' (based on Struts 1.0 relase):
> 
> See http://sourceforge.net/projects/pow2acl
> 
> Unfortunately, the package lacks an overview documentation and direct code
> examples...
> 
> I found that Mr. Nic Hobs already developed a Role-Based Actions system
> (http://www.husted.com/struts/resources/struts-security.htm),
> anyway I try to make a simple description of the acl system (I apologize for
> my english ;^)
> 
> The acl uses user, group, role and permission entities data (persisted into
> a relational database) to execute queries like:
> 
> - is user in a certain group ?
> - is user in a certain role ?
> - has user a certain permission ?
> - has user in a given group a certain role ?
> etc.
> 
> These queries are wrapped into the ACLDAO object, who uses JDBC to execute
> the statements versus a fixed database schema.
> 
> The integration with Struts actions happens using the following classes:
> 
> ACLAction and ACLActionServlet.
> 
> ACLAction is an abstract class that extends Action and adds the
> 'validatePermission' hook method:
> 
>     /**
>      *  Validate user permissions.
>      *  <br>
>      *  This is an hook method; this default implementation always returns
> true.<br>
>      *  Subclass this class and make your own implementation.
>      *
>      *  @param user   the current User object.
>      *  @param acl    the data access object for ACL validation.
>      *  @param errors the ActionError list to fill with possible errors.
>      *  @return true if user has permissions for execute this action,
>      *          false otherwise.
>      */
>     public boolean validatePermissions(User user, ACLDAO acl,
> HttpServletRequest request, ActionErrors errors)
>     {
>         return true;
>     }
> 
> it uses the User object and ACLDAO to check permissions, roles, etc.
> ACLAction subclasses can override validatePermissions and provide the
> 'security' statements.
> The method returs true or false.
> 
> ACLActionServlet extends ActionServlet;
> ovverrides processActionPerform method, checking if the input action is an
> instance of ACLAction (a subclass of).
> If this is true, processActionPerform checks for valid user, then calls
> ACLAction.validatePermissions method
> (note that the default implementation returns always true).
> If validatePermission returns false, ACLActionServlet do:
> 
> return mapping.findForward(ACLAction.ACL_FWD_NOPERMISSIONS);
> 
> else do
> 
> ActionForward forward = action.perform(mapping, formInstance, request,
> response);
> return (forward);
> 
> Into the view (the jsp pages), it is possible to use custom tags like:
> 
> <acl:hasUserPermission permission="DBAadmin" group="admin">
>      <a href="deleteTable.jsp">|delete table|</a>
> </acl:hasUserPermission>
> 
> or
> 
> <acl:isUserInRole role="admin">
>    <a href="admin/index.jsp">admin store items</a>
> </acl:isUserInRole>
> 
> or
> 
> <acl:isUserInRole role="projectmanager" redirect="login.do"/>
> 
> for template pages (you cannot use redirection into 'content' jsp pages)
> 
> etc.
> 
> There is also a database frontend web application to manage the acl tables
> and a suite of Cactus tests for the tag library (and thus for the data
> access).
> The package is builded using also  pow2Toolkit (a 'common' repository of
> classes) that has its own 'user' philosophy.
> We should release pow2Toolkit  as open source soon... (the problem is
> time...)
> 
> Hope it can be useful;
> 
> Luca
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>