Open Stack

On Thursday, May 7, 2015, Adam Young <ayoung at redhat.com> wrote:

>  On 05/06/2015 06:54 PM, Hu, David J (Converged Cloud) wrote:
>
> david8hu> One of the first thing we have to do is get all of our glossary
> straight J  I am starting to hear about “capability”.  Are we talking
> about “rule” in oslo policy terms? Or “action” in nova policy terms? Or
> this is something new.  For example, “compute:create_instance” is a “rule”
> in oslo.policy enforce(…) definition,  “compute:create_instance” is an
> “action” in nova.policy enforce(…) definition.
>
>
> By capability, I ( think I ) mean  Action in Nova terms, as I am trying to
> exclude the internal rules that policy lets you define.  However, to
> further muddy the water, you can actually enforce on one of these rules./
> For example, the Keystone server enforces on "admin_required"  for the V2
> API.
>
> The term capability has been thrown around a few times and I picked it
> up.  Really what I want to delineate is the point in the code at which
> policy gets enforced.
>

I completely agree with Adam. Capabilities are the "actions" a user is
allowed to perform. But I'd rather talk in terms of authorized HTTP API
calls.

I've tossed around the idea of something like GET /capabilities where the
response included something analogous to a list of APIs where the user
(i.e. current token / authorization context) match the relevant policy
rules -- but implementing that concept in more than one service would be a
huge challenge.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150507/40c9415b/attachment.html>