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
