implement rbac support for identity

Registered by Andre Aranha on 2014-10-06

Summary:
Implement RBAC on actions making calls to the identity service, in Identity dashboard.

Motivation:
Dashboards should reflect the policies permissions, if a user has permission to list users, that option should appear in the Identity dashboard.

Use Case #1
    As a cloud admin I want to define new roles to be used in my cloud: cloud_admin, the role to manager the cloud, domain admin for the domain, project admin, the role to manager the project the user is the admin, and member, the usual user with no admin privilege.

As seen in code, for some operations, like list users, it's required that the user has the role admin ( https://github.com/openstack/horizon/blob/master/openstack_dashboard/api/keystone.py#L295 ). This is undesirable in the Use Case #1, because I renamed and split the role admin to cloud_admin, domain_admin and project_admin.

Use Case #2
I want to give permission to users with role member in a domain to list users and projects.

With the currently implementation this is not possible, because of the same case above, as these users are not admins, the Horizon Keystone client won't give permission to them to list users and projects.

Description:
In order to implement this feature it's required to remove the parameter in Horizon Keystone client that requires the user to be admin and rely only on the policies ( https://github.com/openstack/horizon/blob/master/openstack_dashboard/api/keystone.py#L122 ), also modify the functions that makes calls with parameter admin.

UX:
The UX will not be modified, except that it will show dashboards and panels for non-admin users as well.

Outside Dependencies:
N/A

Requirements Update Required:
N/A

Doc Impact:
N/A

Blueprint information

Status:
Complete
Approver:
None
Priority:
Undefined
Drafter:
Andre Aranha
Direction:
Needs approval
Assignee:
Andre Aranha
Definition:
Obsolete
Series goal:
None
Implementation:
Unknown
Milestone target:
None
Completed by
David Lyle on 2014-11-24

Related branches

Sprints

Whiteboard

[Lin Oct-6-2014] Andre, the Identity panels seems already have RBAC in place. What calls to Identity service are you looking to add RBAC to?
As discussed in the chat, I tested it and it's not working 100%, because for non-admin user the panel is not even showing

Gerrit topic: https://review.openstack.org/#q,topic:identity_rbac,n,z

Addressed by: https://review.openstack.org/126640
    Implementing RBAC in Identity

[Lin Oct-7-2014] hey Andre, can you format the bp this way: https://blueprints.launchpad.net/horizon/+spec/template It would help the reviewers to understand the background of the patch you submitted.

[tsufiev Oct-9-2014] Passing `admin=True` in a `keystoneclient()` call is entirely unrelated to the roles that are required to perform an action. Actually it chooses between admin and public/internal endpoint of Keystone. There are no differences between them for Keystone V3, but for Keystone V2 the API provided on public endpoint has less capabilities than the admin one, namely, it isn't able to operate on /users. Thus, removing `admin=True` will certainly break users-related functionality for Horizon instance running on a Keystone V2 service. Please take a notice of openstack_dashboard/conf/keystone_policy.json file - editing it is a right way of splitting permissions between different admin roles.

Gerrit topic: https://review.openstack.org/#q,topic:bp/identity-rbac,n,z

[2014-11-24 | david-lyle] I believe the general direction for keystone is to move away from utilizing the 3 separate interfaces for the keystone API. If they make this change, we should support removing forcing "admin=" value to the client. Beyond that, the is_superuser call has recently been changed in django_openstack_auth to support a wider variety of roles [1]. Once a newer version of that library is released. The changes proposed in the patch are not necessary.

[1] https://github.com/openstack/django_openstack_auth/commit/f9d22f16c2d9e21998829565d2a32732acebbe1f

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.