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