Georgy, Pecan hook functions (http://pecan.readthedocs.org/en/latest/hooks.html) are passed a `state` argument, which has a couple of attributes you can make use of. Starting at the `before` hook, you have access to `state.controller`, which is the @pecan.expose() decorated controller/function that pecan discovered in its routing algorithm (if any):
class MyHook(pecan.hooks.PecanHook): def before(self, state): assert isinstance(state.request, webob.Request) assert state.controller.__func__ is MyController.index.__func__ # for examples’ sake, to illustrate the *type* of the controller attribute. This could be False, depending on the URL path :) Important to note is that `state.controller` will be `None` in the `on_route` hook, because the routing of the path to controller hasn’t actually happened at that point. --- Ryan Petrello Senior Developer, DreamHost ryan.petre...@dreamhost.com On Jan 9, 2014, at 6:44 PM, Georgy Okrokvertskhov <gokrokvertsk...@mirantis.com> wrote: > Hi Rayan, > > Thank you for sharing your view on SecureController. That is always good to > hear info from the developers who are deeply familiar with the code base. > > I like an idea with hooks. If we go this path, we will need to have an > information about a method of a particular controller which will be called if > authorization is successful. In current keystone implementation this is done > by wrapper which knows the actual method name it wraps. This allows one to > write simple rules for specific methods like "identity:get_policy": > "rule:admin_required", > > Do you know if you are inside hook code is there a way to obtain information > about router and method which will be called after hook? > > Thanks > Georgy > > > On Thu, Jan 9, 2014 at 2:48 PM, Ryan Petrello <ryan.petre...@dreamhost.com> > wrote: > As a Pecan developer, I’ll chime in and say that I’m actually *not* a fan of > SecureController and its metaclass approach. Maybe it’s just too magical for > my taste. I’d give a big thumbs up to an approach that involves utilizing > pecan’s hooks. Similar to Kurt’s suggestion with middleware, they give you > the opportunity to hook in security *before* the controller call, but they > avoid the nastiness of parsing the WSGI environ by hand and writing code that > duplicates pecan’s route-to-controller resolution. > > --- > Ryan Petrello > Senior Developer, DreamHost > ryan.petre...@dreamhost.com > > On Jan 9, 2014, at 3:04 PM, Georgy Okrokvertskhov > <gokrokvertsk...@mirantis.com> wrote: > > > Hi Adam, > > > > This looks very interesting. When do you expect to have this code available > > in oslo? Do you have a development guide which describes best practices for > > using this authorization approach? > > > > I think that for Pecan it will be possible to get rid of @protected wrapper > > and use SecureController class as a parent. It has a method which will be > > called before each controller method call. I saw Pecan was moved to > > stackforge, so probably it is a good idea to talk with Pecan developers and > > discuss how this part of keystone can be integrated\ supported by Pecan > > framework. > > > > > > On Wed, Jan 8, 2014 at 8:34 PM, Adam Young <ayo...@redhat.com> wrote: > > We are working on cleaning up the Keystone code with an eye to Oslo and > > reuse: > > > > https://review.openstack.org/#/c/56333/ > > > > > > On 01/08/2014 02:47 PM, Georgy Okrokvertskhov wrote: > >> Hi, > >> > >> Keep policy control in one place is a good idea. We can use standard > >> policy approach and keep access control configuration in json file as it > >> done in Nova and other projects. > >> Keystone uses wrapper function for methods. Here is a wrapper code: > >> https://github.com/openstack/keystone/blob/master/keystone/common/controller.py#L111. > >> Each controller method has @protected() wrapper, so a method information > >> is available through python f.__name__ instead of URL parsing. It means > >> that some RBAC parts anyway scattered among the code. > >> > >> If we want to avoid RBAC scattered among the code we can use URL parsing > >> approach and have all the logic inside hook. In pecan hook WSGI > >> environment is already created and there is full access to request > >> parameters\content. We can map URL to policy key. > >> > >> So we have two options: > >> 1. Add wrapper to each API method like all other project did > >> 2. Add a hook with URL parsing which maps path to policy key. > >> > >> > >> Thanks > >> Georgy > >> > >> > >> > >> On Wed, Jan 8, 2014 at 9:05 AM, Kurt Griffiths > >> <kurt.griffi...@rackspace.com> wrote: > >> Yeah, that could work. The main thing is to try and keep policy control in > >> one place if you can rather than sprinkling it all over the place. > >> > >> From: Georgy Okrokvertskhov <gokrokvertsk...@mirantis.com> > >> Reply-To: OpenStack Dev <openstack-dev@lists.openstack.org> > >> Date: Wednesday, January 8, 2014 at 10:41 AM > >> > >> To: OpenStack Dev <openstack-dev@lists.openstack.org> > >> Subject: Re: [openstack-dev] [Solum][Pecan][Security] Pecan > >> SecureController vs. Nova policy > >> > >> Hi Kurt, > >> > >> As for WSGI middleware I think about Pecan hooks which can be added before > >> actual controller call. Here is an example how we added a hook for > >> keystone information collection: > >> https://review.openstack.org/#/c/64458/4/solum/api/auth.py > >> > >> What do you think, will this approach with Pecan hooks work? > >> > >> Thanks > >> Georgy > >> > >> > >> On Tue, Jan 7, 2014 at 2:25 PM, Kurt Griffiths > >> <kurt.griffi...@rackspace.com> wrote: > >> You might also consider doing this in WSGI middleware: > >> > >> Pros: > >> • Consolidates policy code in once place, making it easier to audit > >> and maintain > >> • Simple to turn policy on/off – just don’t insert the middleware > >> when off! > >> • Does not preclude the use of oslo.policy for rule checking > >> • Blocks unauthorized requests before they have a chance to touch the > >> web framework or app. This reduces your attack surface and can improve > >> performance (since the web framework has yet to parse the request). > >> Cons: > >> • Doesn't work for policies that require knowledge that isn’t > >> available this early in the pipeline (without having to duplicate a lot of > >> code) > >> • You have to parse the WSGI environ dict yourself (this may not be a > >> big deal, depending on how much knowledge you need to glean in order to > >> enforce the policy). > >> • You have to keep your HTTP path matching in sync with with your > >> route definitions in the code. If you have full test coverage, you will > >> know when you get out of sync. That being said, API routes tend to be > >> quite stable in relation to to other parts of the code implementation once > >> you have settled on your API spec. > >> I’m sure there are other pros and cons I missed, but you can make your own > >> best judgement whether this option makes sense in Solum’s case. > >> > >> From: Doug Hellmann <doug.hellm...@dreamhost.com> > >> Reply-To: OpenStack Dev <openstack-dev@lists.openstack.org> > >> Date: Tuesday, January 7, 2014 at 6:54 AM > >> To: OpenStack Dev <openstack-dev@lists.openstack.org> > >> Subject: Re: [openstack-dev] [Solum][Pecan][Security] Pecan > >> SecureController vs. Nova policy > >> > >> > >> > >> > >> On Mon, Jan 6, 2014 at 6:26 PM, Georgy Okrokvertskhov > >> <gokrokvertsk...@mirantis.com> wrote: > >> Hi Dough, > >> > >> Thank you for pointing to this code. As I see you use OpenStack policy > >> framework but not Pecan security features. How do you implement fine grain > >> access control like user allowed to read only, writers and admins. Can you > >> block part of API methods for specific user like access to create methods > >> for specific user role? > >> > >> The policy enforcement isn't simple on/off switching in ceilometer, so > >> we're using the policy framework calls in a couple of places within our > >> API code (look through v2.py for examples). As a result, we didn't need to > >> build much on top of the existing policy module to interface with pecan. > >> > >> For your needs, it shouldn't be difficult to create a couple of decorators > >> to combine with pecan's hook framework to enforce the policy, which might > >> be less complex than trying to match the operating model of the policy > >> system to pecan's security framework. > >> > >> This is the sort of thing that should probably go through Oslo and be > >> shared, so please consider contributing to the incubator when you have > >> something working. > >> > >> Doug > >> > >> > >> > >> Thanks > >> Georgy > >> > >> > >> On Mon, Jan 6, 2014 at 2:45 PM, Doug Hellmann > >> <doug.hellm...@dreamhost.com> wrote: > >> > >> > >> > >> On Mon, Jan 6, 2014 at 2:56 PM, Georgy Okrokvertskhov > >> <gokrokvertsk...@mirantis.com> wrote: > >> Hi, > >> > >> In Solum project we will need to implement security and ACL for Solum API. > >> Currently we use Pecan framework for API. Pecan has its own security model > >> based on SecureController class. At the same time OpenStack widely uses > >> policy mechanism which uses json files to control access to specific API > >> methods. > >> > >> I wonder if someone has any experience with implementing security and ACL > >> stuff with using Pecan framework. What is the right way to provide > >> security for API? > >> > >> In ceilometer we are using the keystone middleware and the policy > >> framework to manage arguments that constrain the queries handled by the > >> storage layer. > >> > >> http://git.openstack.org/cgit/openstack/ceilometer/tree/ceilometer/api/acl.py > >> > >> and > >> > >> http://git.openstack.org/cgit/openstack/ceilometer/tree/ceilometer/api/controllers/v2.py#n337 > >> > >> Doug > >> > >> > >> > >> Thanks > >> Georgy > >> > >> _______________________________________________ > >> OpenStack-dev mailing list > >> OpenStack-dev@lists.openstack.org > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >> > >> > >> _______________________________________________ > >> OpenStack-dev mailing list > >> OpenStack-dev@lists.openstack.org > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >> > >> > >> > >> -- > >> Georgy Okrokvertskhov > >> Technical Program Manager, > >> Cloud and Infrastructure Services, > >> Mirantis > >> http://www.mirantis.com > >> Tel. +1 650 963 9828 > >> Mob. +1 650 996 3284 > >> > >> _______________________________________________ > >> OpenStack-dev mailing list > >> OpenStack-dev@lists.openstack.org > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >> > >> > >> _______________________________________________ > >> OpenStack-dev mailing list > >> OpenStack-dev@lists.openstack.org > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >> > >> > >> > >> -- > >> Georgy Okrokvertskhov > >> Technical Program Manager, > >> Cloud and Infrastructure Services, > >> Mirantis > >> http://www.mirantis.com > >> Tel. +1 650 963 9828 > >> Mob. +1 650 996 3284 > >> > >> _______________________________________________ > >> OpenStack-dev mailing list > >> OpenStack-dev@lists.openstack.org > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >> > >> > >> > >> -- > >> Georgy Okrokvertskhov > >> Technical Program Manager, > >> Cloud and Infrastructure Services, > >> Mirantis > >> http://www.mirantis.com > >> Tel. +1 650 963 9828 > >> Mob. +1 650 996 3284 > >> > >> > >> _______________________________________________ > >> OpenStack-dev mailing list > >> > >> OpenStack-dev@lists.openstack.org > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > > -- > > Georgy Okrokvertskhov > > Technical Program Manager, > > Cloud and Infrastructure Services, > > Mirantis > > http://www.mirantis.com > > Tel. +1 650 963 9828 > > Mob. +1 650 996 3284 > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > -- > Georgy Okrokvertskhov > Technical Program Manager, > Cloud and Infrastructure Services, > Mirantis > http://www.mirantis.com > Tel. +1 650 963 9828 > Mob. +1 650 996 3284 > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev