Proposal for an ACLs Plug-in

[Robert Impey]

I have an idea for how to implement access control lists in projects
that use the Public HTML plug-in. It is inspired by ACLs in the Zend
Framework, but I think should be simpler and less confusing.

We need to have lists of resources and roles defined for each project.
Roles should be able to 'inheritit' the resources of other roles. The
data might be defined in an XML configuration file for each project.

For example, let's consider a CMS. Our roles might be 'guest',
'author', 'moderator', 'editor' and 'admin'. Our resources might be
'public_pages', 'write_article', 'review_comments',
'edit_own_articles', 'edit_all_articles' and 'modify_users'. Our XML
file might look like this.

<?xml version="1.0" encoding='UTF-8'?>
<roles>
<role>
<role name="guest"><resources><resource>public_pages</resource></role>
<role name="author"
inherits="guest"><resources><resource>write_article</resource></role>
<role name="moderator"
inherits="author"><resources><resource>review_comments</resource></
role>
<role name="editor"
inherits="moderator"><resources><resource>edit_own_articles</
resource></role>
<role name="admin"
inherits="editor"><resources><resource>modify_users</resource></role>
</roles>

In PublicHTML_HaddockHTTPResponse, we could defined a method call
'is_accessible()' which simply returns 'true'. index.php in the Public
HTML plug-in should call this function in an 'if' statement before
running the HTTP response object that has been requested.
OurProject_HTMLPage (the class that all HTML page classes extend)
should implement an interface called
AccessControlLists_ACLHTTPResponse which will require a method called
'get_acl_resource_name()'. OurProject_HTMLPage::is_accessible() might
be overridden as follows:

public function is_accessible()
{
return
AccessControlLists_AccessControlHelper::http_response_is_accessible($this-
>get_acl_resource_name());
}

Any comments or suggestions would be gratefully apreciated.

--
You received this message because you are subscribed to the Google Groups "Haddock CMS" group.
To post to this group, send email to haddo...@googlegroups.com.
To unsubscribe from this group, send email to haddock-cms...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/haddock-cms?hl=en.

[Saul Howard]

This sounds excellent, and much needed.

I recently wrote a User Login plugin because I couldn't get round to
rewriting the Admin Login code in the PublicHTML to include general
Users. It does work, but is inefficient. It would be great if there
was only one role and resources system. More secure too, of course.

Will you be starting to add these features yourself? I have a lot of
interest in using this for some clients, so I will be able to work on
it. Perhaps it would be best if you could start the framework for the
system, if that's possible.

Just some thoughts:

I love the idea of roles inheriting access to resources.

The idea of a is_accessible() function in OurProject_HTMLPage is easy
and clean, I think it's perfect.

I'm wondering if one resource-name per page-class is enough? It
probably is. Tagging pages would give more control, but I doubt it's
necessary, I'll think about it.

Will these roles be the same as in the login system, that are
currently set in the session? Will there be default admin roles, like
the ones currently hardcoded (Developer, Admin, User)? Does this
affect the login system at all?

As I said, I'll go away and consider my use-cases now.

Saul.

[Robert Impey]

On 6 May 2010 05:39, Saul Howard <saulh...@gmail.com> wrote:
> This sounds excellent, and much needed.
>
> I recently wrote a User Login plugin because I couldn't get round to
> rewriting the Admin Login code in the PublicHTML to include general
> Users. It does work, but is inefficient. It would be great if there
> was only one role and resources system. More secure too, of course.
>

This should work with that plug-in without a problem.

> Will you be starting to add these features yourself? I have a lot of
> interest in using this for some clients, so I will be able to  work on
> it. Perhaps it would be best if you could start the framework for the
> system, if that's possible.
>

I should be able to get the plug-in started shortly. I'll write it to
work with the version of the Public HTML plug-in (rather than the core
module). It shouldn't be difficult to adapt the core module (if you
are still using that).

> Just some thoughts:
>
> I love the idea of roles inheriting access to resources.
>
> The idea of a is_accessible() function in OurProject_HTMLPage is easy
> and clean, I think it's perfect.
>
> I'm wondering if one resource-name per page-class is enough? It
> probably is. Tagging pages would give more control, but I doubt it's
> necessary, I'll think about it.

>\

That might be problematic. If a user can access one named resource but
not another, what should happen? I'm not sure that such a system would
be easily understood. When it comes to issues of security, we want as
little confusion as possible.

> Will these roles be the same as in the login system, that are
> currently set in the session? Will there be default admin roles, like
> the ones currently hardcoded (Developer, Admin, User)? Does this
> affect the login system at all?
>

Once this plug-in is working, an overhaul of similar systems might be in order.

> As I said, I'll go away and consider my use-cases now.
>

Cheers,

Robert Impey

--
Rob Impey