Open Stack

Salvatore,

We are looking at implementing a similar feature in glance. It is an open
question to me whether or not this level of authz specification can live in
the policy engine at all. But it definitely seems to be a valid use case to
me (i.e. I couldn't agree with your solution #1.)

Blueprint:
https://blueprints.launchpad.net/glance/+spec/api-v2-property-protection


On Tue, Apr 30, 2013 at 4:09 PM, Mellquist, Peter <peter.mellquist at hp.com>wrote:

>  Hi Salvatore,****
>
> ** **
>
> Have you considered using the Keystone ‘role’ for this? For example, for
> this service you might have two roles, a ‘user’ and ‘admin’ role. When the
> Keystone middleware validates the request, e.g. token, the service will be
> able to access the role and if it is ‘admin’ then additional attributes
> could then be included in the response.****
>
> ** **
>
> Peter.****
>
> ** **
>
> *From:* Salvatore Orlando [mailto:sorlando at nicira.com]
> *Sent:* Tuesday, April 30, 2013 3:57 PM
> *To:* OpenStack Development Mailing List
> *Subject:* [openstack-dev] A (probably) interesting authZ question****
>
> ** **
>
> Hi,****
>
> ** **
>
> I am sending this to a broader audience since recently for a patch on
> openstack-network we've come across a peculiar authZ problem, which might
> have been already solved in some other project.****
>
> Basically some API resources have composite attributes, ie: attributes
> whose value is a dict.****
>
> In some case there might be a need to authorize access to such attributes.
> ****
>
> ** **
>
> For instance, in this specific case we have:****
>
> ** **
>
> "router" : {****
>
>    <... some router stuff ..>****
>
>    "external_gateway_info" : {****
>
>         "network_id": "some_uuid",****
>
>         "enable_snat": "true"****
>
>    }****
>
>    < .. some more router stuff ... >****
>
> }****
>
> ** **
>
> and we would like to say that the policy for setting enable_snat must be
> rule:admin_only.****
>
> there are several options, among which:****
>
> ** **
>
> 1) this way of doing authZ does not make sense at all. authZ should be
> enforced on resources not single attributes****
>
> 2) If the particular attribute comes from some specific extension, instead
> of policing access one should be allowed to turn administratively on/off
> the extension itself****
>
> 3) We should have a rule check for sub-attributes (like FieldCheck in
> quantum/policy.py).****
>
> 4) The enable_snat attribute should be moved to the first-level resource,
> and authZ checked as with any other attribute****
>
> ** **
>
> any opinion on the subject would be greatly appreciated.****
>
> ** **
>
> Regards,****
>
> Salvatore****
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130430/e81f1870/attachment-0001.html>