Rationalize how user roles are obtained at authentication time

Registered by Henry Nash on 2013-07-03

The auth/token controllers have different strategies of obtaining the list of user project/domain roles at authentication time - with varied use of the optional project id available in the identity driver authenticate call. Only the v2 authenticate_local uses this feature, the others (external and token) and all v3 read the roles for the project after authenticating with just the user details. Further the v2 code builds the roles lists by hand (allowing for groups), while the v3 version calls the "get_user_roles_for_project" (or "domain", which does that for you. This mismatch is not only bad for maintenance, but is also wrong in some cases (e.g. if the ONLY role you had on a project was by nature of group membership, authenticating locally would fail).

We should rationalize this - and always just authenticate for the user and then call the "get_user_roles_for_project" (or "domain") within the controller.

Blueprint information

Status:
Complete
Approver:
Henry Nash
Priority:
Medium
Drafter:
Henry Nash
Direction:
Needs approval
Assignee:
Henry Nash
Definition:
Approved
Series goal:
Accepted for havana
Implementation:
Implemented
Milestone target:
milestone icon 2013.2
Started by
Henry Nash on 2013-07-05
Completed by
Henry Nash on 2013-07-13

Related branches

Sprints

Whiteboard

Gerrit topic: https://review.openstack.org/#q,topic:bp/authenticate-role-rationalization,n,z

Addressed by: https://review.openstack.org/35897
    Rationalize how we get roles after authentication in the controllers

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.