[Catalyst] Authorization ACL: future plans?

[Jonathan Rockway]

* On Fri, Jun 06 2008, ivorw wrote:
> Hi guys,
>
> (Yuval please note: this concerns one of your modules)
>
> Are there any plans afoot to build on
> Catalyst::Plugin::Authorization::ACL? I have a requirement for a couple
> of enhancements, and I'd like to sound out the list before jumping in
> and coding.
>
>
> 1. I'd quite like the idea of a generic "resource", that users have
> access to, rather than just a controller method. The resource could be
> or correspond to a file on the server's fs, a wiki page, a diary
> appointment, etc.
>
> The resource would have a set of permissions, controlled through the model:
>  * See   (whether this resource actually appears at all)
>  * Read (Are the contents of the resource visible/executable?)
>  * Modify
>  * Delete
>  * Grant (who can change the permissions for this resource)

I don't think a Catalyst plugin is where this sort of code belongs.  It
belongs in a layer unrelated to Catalyst.  I also don't think this can
be done generically enough to make it useful.  (Too generic and it won't
save any time, too specific and you'll be the only user.)

For something DBIx::Class-specific, look at
DBIx::Class::Schema::RestrictWithObject.  Basically, you have an object
that does the access control (per-resultset), and your application never
sees data that the user isn't allowed to see.  This is the right level
of generic-ness.

Authorization::ACL is completely differnet,BTW.  It's nice for walling
off part of your application; mainly so you don't have to check
$c->user_exists for every action that $c->user touches.  But, it doesn't
try to guess what your application's data means, it just turns part of
the app off based on some rules you set up.  Again, the right level of
generic-ness.

What I'm trying to say is that access control and C::P::A::ACL are two
different things.  Catalyst shouldn't even be in your mind when you are
designing the access rules and code for your data.

> The resource also has an owner (user) and a group (role).
> Each of the permissions above can be set to one of 'owner', 'group',
> 'world' or none.
>
> Proposed module name: Catalyst::Plugin::Authorization::ACL::Resource
>
> 2. Full blown access control lists
>
> For more sophisticated requirements, we have an actual list:
>
> Include: list of entities
> Exclude: list of entities
>
>
> each entity can be one of the following:
>  * A user
>  * 'owner'
>  * A role
>  * 'group'
>  * An ACL (i.e. nesting)
>
> This enhances option 1 above by allowing the permission to be an ACL
> besides 'owner', 'group', 'world' or none.
>
> Proposed module name: Catalyst::Plugin::Authorization::ACL::Full
>
> What do people think? Feedback please.
>
> By the way in case you are wondering, I am looking to write a CMS that
> sits on top of Catalyst.

Write the CMS first, then factor out the access control code.  If you do
it the other way around, it probably won't turn out the way you want.
(Nothing is worse than writing a library and then having your
application that uses it work around it.  Trust me, I've done that.)

Regards,
Jonathan Rockway

-- 
print just => another => perl => hacker => if $,=$"