Re: [Catalyst] Authorization ACL: future plans?
On Wed, Jun 11, 2008 at 07:52:27PM +0100, ivorw wrote: > Jonathan, thank you for a most thought provoking reply. I couldn't work > out whether you were playing devil's advocate, or if you completely > believe that my generic approach is doomed to failure. He's half right. Making something completely generic will be impossible - or you'll end up implementing what amounts to a data-driven programming language, and it'll be as hard work to configure usefully as, say, windows authz. Making something that provides a nice structure for building authorization systems is very possible; this shouldn't be a Catalyst::Model, it should be a general CPAN module. Then you define a set of APIs that different components in the system talk, and your app's requirements become one set of implementations of those APIs. Then you build a Catalyst::Whatever that acts as an adaptor from Catalyst to your authz model. There's no need necessarily to do all this up front, but you should bear in mind that authorization structures -do- vary wildly from app to app so however you do it some consumers of it will need to replace one or more of the components. Consider the way Plugin::Authentication separates realms, credentials and stores as a reasonable example of the concept. The guts of Authorization::ACL may be inspiration as a way to integrate this security into your controller paths; personally I think I'd be more interested in being able to integrate it into my model - so I can require a certain permission to call $obj->update on a DBIC row or whatever. Might be interesting to start a thread on the DBIC list about model level security if you were so inclined. -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Authorization ACL: future plans?
Jonathan, thank you for a most thought provoking reply. I couldn't work out whether you were playing devil's advocate, or if you completely believe that my generic approach is doomed to failure. I may get it wrong, but I will learn from the experience. There is no failure, only feedback. Saying "It can't be done" is a red rag to a bull with me, and stimulates me to invoke the Perl virtue of hubris. Comments below: Jonathan Rockway wrote: > * On Fri, Jun 06 2008, ivorw wrote: > >> 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.) > Do you have any evidence for this? Can you point me to someone else's failed attempt to do it; that would be very much appreciated. > 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. > Thank you! I'll look at D::C::S::RWO and work out whether it meets my needs. I'm now looking at a Catalyst::Model:: module rather than a plugin, as that is where I now feel this functionality should go. > 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 point is that I'm not designing the access rules. My admin users (i.e. my clients) are deciding who has access to their data, and I need to provide flexibility. > >> [snip] >> >> 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.) > Sorry, that won't do. I have some very much simpler needs for access control than the CMS. I'm going to design the access control layer to meet the immediate requirements, with the CMS in mind as a future requirement. Even if nobody else uses my module, I don't care, as I have multiple applications for it. Anyway, I've had a reply off-list from someone who has applications, who is interested in working with me to develop the modules. Ivor. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Authorization ACL: future plans?
* 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 $,=$" ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Authorization ACL: future plans?
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) 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. Ivor. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
