[openstack-dev] [Quantum] attribute authorization

Salvatore Orlando sorlando at nicira.com
Mon Jul 23 21:10:25 UTC 2012


I addressed the same problem on the public networks branch in gerrit in WIP
at the moment while we finalize decision on how it should look like on
public API.

Let me know your thoughts about the implementation. If that is good for
you, we can just use that.
Otherwise, I'll be extremely happy to address all your comments :)

You've already done such a lot of great work, that I think it's time for me
to address some real issues as well!

Salvatore

On 23 July 2012 19:58, Robert Kukura <rkukura at redhat.com> wrote:

> Given that Salvatore and Sumit were both concerned about the plugins
> doing the authorization for provider network extended attributes (see
> patch set 5 of https://review.openstack.org/#/c/9069/), I've been
> working on a very simple mechanism to move those policy checks into the
> core. This mechanism can be used for core attributes as well as extended
> attributes that require specific authorization to be set or viewed.
>
> The resource attributes map (see quantum/api/v2/attributes.py) currently
> has boolean properties called allow_post, allow_put, and is_visible that
> control whether an attribute can be set via create, set via update, or
> viewed, respectively. My proposed approach is that each of these three
> properties can still be a boolean, but if it is instead a string, that
> string is passed to the policy.check function as the name of an action,
> and the result of the check is used as the boolean would have been used.
>
> Please let me know ASAP whether or not you feel this approach is
> acceptable, or if you've got any questions or better (simple) ideas. I
> hope to have it implemented and included in the next provider-network BP
> patch later today.
>
> Thanks,
>
> -Bob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120723/173ff8f3/attachment-0001.html>


More information about the OpenStack-dev mailing list