Open Stack

(replying on list)

RBAC policy enforce is already implemented on consuming services and default policies are provided by policy.json files (e.g. https://github.com/openstack/nova/blob/master/etc/nova/policy.json ).

We haven't yet implemented a method for services to consume policy blobs from Identity API v3, /v3/policies (which itself is still in development), rather than loading policy.json files.

For an example of scoping RBAC per project, see the admin_or_owner rule in nova's policy.json above.

As for the efficiency of policy storage, I'm not clear on what your concerns are?

-Dolph
________________________________
From: MS. Faraji [ms.faraji at utoronto.ca]
Sent: Wednesday, October 03, 2012 1:34 PM
To: Dolph Mathews
Subject: Question about Keystone RBAC

Hi,

I sent an email to inquire about RBAC implementation in Keystone before, and you generously shared your information. However, there are a couple of questions that I have in mind.
I searched the Internet and documents; however, I did not find useful information about them. I hope you can help me to find it out.

1) Consider the enforce API is implemented, which side should use it? Service or Keystone itself. If Keystone uses this function, how does it know about the action that a user
wants to perform on a resource. If service call it as an API, what is the endpoint? How services use authorization in Keystone?

2) Can roles and associated actions be defined in the scope of project or domain? For example demo can do release in project 1 but not in project 2.

3) Is the plain storage of capabilities ( no data structure) efficient? In terms of required storage space and later lookups.

Thanks in advance for your help and assistance,
I look forward to your response.


Moh,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20121003/3a5a84b1/attachment.html>