listing projects for a user omits those that only have group related roles

Bug #1201487 reported by Henry Nash on 2013-07-15
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
High
Henry Nash

Bug Description

The backend drivers currently support two (very similar) functions:

list_user_projects() and get_projects_for_user(). Both claim to return the list of projects for which a user has a role on. Neither take into account roles by virtue of group membership. They are used in the following ways:

uses list_user_projects() is used by:

- The API GET /users/{user_id}/projects

users get_projects_for_user() is used by

- The diablo GET /users/{user_id}/roleRefs (should we still need to support this?)
- The API GET/tenants, where you get all projects referenced the user in the token (weird)
- An unused function the v2 controller (which we should delete)

We should rationalize the above to use a single function in the driver manager (similar to the way we do get_roles_for_user_and_project() ), that correctly accounts for any projects for a which a user also has roles by virtue of group membership.

If the os-inherit extension is installed, the above function should also take into account roles inherited from the domain.

Dolph Mathews (dolph) on 2013-07-15
Changed in keystone:
status: New → Triaged
tags: added: grizzly-backport-potential
Henry Nash (henry-nash) on 2013-07-17
Changed in keystone:
milestone: none → havana-3
Thierry Carrez (ttx) on 2013-09-05
Changed in keystone:
milestone: havana-3 → havana-rc1
Henry Nash (henry-nash) on 2013-09-05
Changed in keystone:
status: Triaged → In Progress

Reviewed: https://review.openstack.org/45584
Committed: http://github.com/openstack/keystone/commit/fb6b5eba634788ce8976cee798cfcc4330f0570a
Submitter: Jenkins
Branch: master

commit fb6b5eba634788ce8976cee798cfcc4330f0570a
Author: Henry Nash <email address hidden>
Date: Sun Sep 8 21:07:07 2013 +0100

    Rationalize list_user_projects and get_projects_for_user

    These two functions have slightly different implementations and yet neither
    takes into account group or inherited roles. Rationalize these into a single
    list_projects_for_user() that gets the correct list of project refs, allowing
    for group and inherited roles. The public API name, as referenced in the
    policy file, remains as 'list_user_projects' to avoid a policy file change
    at this late stage.

    The most common use cases of the above is via the v2 API, when we need
    to ensure only projects from the default domain are included. Given that
    this means we must inspect each project ref anyway, having a call that
    returns a list of IDs will not be any more efficient than returning the
    project refs and letting the caller extract the IDs.

    Fixes bug #1201487

    Change-Id: I614140639c71dae4dfe501d27eda65e41a78694d

Changed in keystone:
status: In Progress → Fix Committed
Thierry Carrez (ttx) on 2013-10-02
Changed in keystone:
status: Fix Committed → Fix Released
Thierry Carrez (ttx) on 2013-10-17
Changed in keystone:
milestone: havana-rc1 → 2013.2
Alan Pevec (apevec) on 2014-03-30
tags: removed: grizzly-backport-potential
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers