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 <%2B1%20650%20963%209828> >>>> Mob. +1 650 996 3284 <%2B1%20650%20996%203284> >>>> >>>> _______________________________________________ >>>> 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 <%2B1%20650%20963%209828> >> Mob. +1 650 996 3284 <%2B1%20650%20996%203284> >> >> _______________________________________________ >> 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 > listOpenStack-dev@lists.openstack.orghttp://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