On Thursday, May 7, 2015, Adam Young <ayo...@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.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
