v3 API create_user does not use default_project_id

Bug #1662911 reported by Doug Hellmann
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Revision history for this message
Dolph Mathews (dolph) wrote :

v3 has always required authorization to be explicitly granted using a separate call, rather than being implied via a user-attribute. The intent is that user attributes may be set by the user themselves as a preference.

That said, setting the user password attribute acts as an administrative password reset, and we have a separate API for self-service password changes, so it's not exactly consistent.

Revision history for this message
Lance Bragstad (lbragstad) wrote :

This behavior is documented according to our user API reference [0] in the `default_project_id` section. I do agree with Dolph's assessment on the inconsistencies though.

"The ID of the default project for the user. Setting this attribute does not grant any actual authorization on the project, and is merely provided for convenience. Therefore, the referenced project does not need to exist within the user domain. (Since v3.1) If the user does not have authorization to their default project, the default project is ignored at token creation. (Since v3.1) Additionally, if your default project is not valid, a token is issued without an explicit scope of authorization."

[0] http://developer.openstack.org/api-ref/identity/v3/index.html?expanded=create-user-detail

Revision history for this message
Doug Hellmann (doug-hellmann) wrote :

stevemar may have more insight into what the real problem was, I was trying to describe what we encountered when we tried to open pike for development. The fix in https://review.openstack.org/#/c/430982 allowed us to get past the failure in grenade's setup step.

Revision history for this message
Sean Dague (sdague) wrote :

I think this is definitely a regression from a user expectation point of view, for no clear reason.

If a user provides a default_project_id, I can't imagine a circumstance where they would want no permission with that project.

I do get that keystone wants lots of flexibility with roles, but this is definitely a backwards step in the basic use case, and puts more logic client side to create the correct user perceived results.

Revision history for this message
Lance Bragstad (lbragstad) wrote :

In the event a deployment allows users to update their own user attributes, would we expect an administrator to clean up a rogue assignment if a user provides a project ID they shouldn't have access to?

Revision history for this message
Graham Hayes (grahamhayes) wrote :

This is now blocking the designate gates.

This seems like a pretty major change (considering it broke at least grenade + designate) with no warning.

Changed in designate:
status: New → Triaged
importance: Undecided → Critical
assignee: nobody → Graham Hayes (grahamhayes)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to designate (master)

Related fix proposed to branch: master
Review: https://review.openstack.org/433052

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to designate (master)

Reviewed: https://review.openstack.org/433052
Committed: https://git.openstack.org/cgit/openstack/designate/commit/?id=8eef7e103bf906d99c661b5dc5024b31b794d4fd
Submitter: Jenkins
Branch: master

commit 8eef7e103bf906d99c661b5dc5024b31b794d4fd
Author: Graham Hayes <email address hidden>
Date: Mon Feb 13 13:19:42 2017 +0000

    Fix broken grenade gate

    in keystone v3, the openstack cli works completely
    differently when creating a user.

    The explictly adds the designate user to the designate project with
    the "Member" role.

    This was previously found in the main grenade project.

    Change-Id: I3addc95dce8f4f86c108ab18ace2b80003d22519
    Related-Bug: #1662911

Revision history for this message
David Stanek (dstanek) wrote :

As far as I know this isn't a new change. I think of it like a fix to a security bug. If a user is able to edit their own default project ID we need to make sure they have a role on it right? Otherwise I could update my user with someone else's project id to gain access.

Part of the redesign around v3 was to make it a richer interface by making it possible to have a more granular policy. We wanted the ability to delegate tasks down the admin chain. Allow a domain admin to create projects in a domain, allow a user to edit their own data, etc. This leaves the cloud admin (cloud operators) out of day-to-day user tasks.

Revision history for this message
Lance Bragstad (lbragstad) wrote :

I'm going to mark this as invalid based on the security concerns highlighted in comment #9. Please feel free to continue using the thread for discussion as needed.

Changed in keystone:
status: New → Opinion
status: Opinion → Invalid
Changed in designate:
status: Triaged → Invalid
assignee: Graham Hayes (grahamhayes) → nobody
importance: Critical → Undecided
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers