Sphoof ACL component proposal
Jacob Verloop
Hey folks,
After months of watching the sphoof library grow I decided to contribute to the project recently. I wrote a small patch for the config component so far. I never did OSS before except using it. It felt right and motivated me to write a proposal for an ACL (Access Control List) component.
I guess almost every application requires some kind of authorization. Even though it wasn't a common phenomenon, access control management remains a very importent aspect of building applications. So instead of per-project solutions it would be nice to have a secure, flexible and powerful implementation to rely on. This way the repetitive task of access control becomes a lot easier to accomplish.
I personally like the Zend_Acl component but it's implementation feels (at least to me it does) too complex. My idea is to create a component with almost the same features but a much simpler implementation in far fewer lines of code.
Please take a look at my code:
https://bitbucket.org/jacoop/sphoof-v2/src/5c8155d0e1be/lib/acl.php
Resources:
A resource could be anything that requires authorization.
Examples: page, module, service etc.
Subjects:
This could be anything that works with resources.
Examples: user, group, process etc.
Rules:
A rule is a allow/deny definition of a subject/resource/privilege combination (multi-dimensional array).
Examples:
Subject has all privileges on a Resource except delete.
subject1.resource1.create = true
subject1.resource1.read = true
subject1.resource1.update = true
subject1.resource1.delete = false
The same rules but easier:
subject1.resource1.* = true
subject1.resource1.delete = false
(explicit rules have more value than the global ones)
Subject has all the resource privileges:
subject1.*.* = true
All Subjects have all the resource privileges:
*.*.* = true
Subjects are extendable with multiple parent subjects and the rule value is decreasing from first to last added.
Maybe it would be nice to add some shortcuts and a multi-rule method like:
public function allowAll( ) {
$this->addRule( '*', '*', '*', true );
}
public function denyAll( ) {
$this->addRule( '*', '*', '*', false );
}
public function allowResource( $subject ) {
$this->addRule( $subject, '*', '*', true );
}
public function denyResource( $subject ) {
$this->addRule( $subject, '*', '*', false );
}
public function addMultiRule( $subjects, $resources, $privileges, $allow ) {
/** implementation */
}
I hope this is enough to clarify my idea of building an ACL component!
Thanks for reading!
J. Verloop
Berry Langerak
On 02/14/2011 08:24 PM, Jacob Verloop wrote:
>
> After months of watching the sphoof library grow I decided to
> contribute to the project recently. I wrote a small patch for the
> config component so far. I never did OSS before except using it. It
> felt right and motivated me to write a proposal for an ACL (Access
> Control List) component.
>
First of all: thanks a lot for contributing to sphoof, we really
appreciate all the help we can get to improve it!
> I guess almost every application requires some kind of authorization.
> Even though it wasn't a common phenomenon, access control management
> remains a very importent aspect of building applications. So instead
> of per-project solutions it would be nice to have a secure, flexible
> and powerful implementation to rely on. This way the repetitive task
> of access control becomes a lot easier to accomplish.
>
Agreed: user authorisation is a common phenomenon in web applications,
so I wouldn't mind having a micro-framework to put the abstracted code
in. The goals of being flexible yet powerful sound decent to me,
although the "secure" goal really is up to the one implementing the ACL
component (if you don't check the permission before executing an action,
security is flawed ;)).
> I personally like the Zend_Acl component but it's implementation feels
> (at least to me it does) too complex. My idea is to create a component
> with almost the same features but a much simpler implementation in far
> fewer lines of code.
>
I've worked with Zend_Acl in the (not very recent) past. It felt bloated
and over-engineered and too complicated for my liking, much the same as
your conclusion. Nevertheless, you shouldn't underestimate the
complexity of a decent ACL component. If we can do it in a (way) less
complex manner, I'm voting thumbs-up on the ACL micro-framework.
> Please take a look at my code:
>
> https://bitbucket.org/jacoop/sphoof-v2/src/5c8155d0e1be/lib/acl.php
>
I have, and it's an excellent starting point for this discussion, so
kudos! I do have a few concerns and associated remarks when looking at
the class signature. First of all: part of the complexity of Zend_Acl
comes from the fact that roles (or what you call "subjects") are able to
inherit permissions from their ancestors. I've found this to be a
rather complex and annoying trait of Zend_Acl that doesn't seem to add
any direct benefits. I'd rather have it that a user has a role, and that
role contains all possible permissions. That's easier to follow, easier
to debug, and easier to develop.
The other thing: did you account for the fact that when you ask
Sphoof\Acl::hasPermission( $user, $post, 'remove' ), that it actually
should return false? E.g.: is this going to be Deny by default, allow by
exception? Cause I would like to see that ;)
> I hope this is enough to clarify my idea of building an ACL component!
>
It is. Thanks again for contributing!
Cheers,
Berry.