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
[email protected]
On Jan 9, 2014, at 6:44 PM, Georgy Okrokvertskhov
<[email protected]> 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 <[email protected]>
> 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
> [email protected]
>
> On Jan 9, 2014, at 3:04 PM, Georgy Okrokvertskhov
> <[email protected]> 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 <[email protected]> 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
> >> <[email protected]> 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 <[email protected]>
> >> Reply-To: OpenStack Dev <[email protected]>
> >> Date: Wednesday, January 8, 2014 at 10:41 AM
> >>
> >> To: OpenStack Dev <[email protected]>
> >> 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
> >> <[email protected]> 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 <[email protected]>
> >> Reply-To: OpenStack Dev <[email protected]>
> >> Date: Tuesday, January 7, 2014 at 6:54 AM
> >> To: OpenStack Dev <[email protected]>
> >> Subject: Re: [openstack-dev] [Solum][Pecan][Security] Pecan
> >> SecureController vs. Nova policy
> >>
> >>
> >>
> >>
> >> On Mon, Jan 6, 2014 at 6:26 PM, Georgy Okrokvertskhov
> >> <[email protected]> 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
> >> <[email protected]> wrote:
> >>
> >>
> >>
> >> On Mon, Jan 6, 2014 at 2:56 PM, Georgy Okrokvertskhov
> >> <[email protected]> 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
> >> [email protected]
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> [email protected]
> >> 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
> >> [email protected]
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> [email protected]
> >> 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
> >> [email protected]
> >> 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
> >>
> >> [email protected]
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > [email protected]
> > 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
> > [email protected]
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> [email protected]
> 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
> [email protected]
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
