v3 API create_user does not use default_project_id

[Doug Hellmann]

The v3 call to create a user doesn't use the default_project_id argument except to validate it.

https://github.com/openstack/keystone/blob/master/keystone/identity/core.py#L918-L919

This caused problems when updating grenade to allow the ocata->pike tests to run, because the user was not set up with a default role as it had been under V2.

https://review.openstack.org/#/c/427916/1

http://logs.openstack.org/16/427916/1/check/gate-grenade-dsvm-neutron-ubuntu-xenial/56b7a7d/logs/apache/keystone.txt.gz?level=WARNING#_2017-02-08_13_48_57_247
http://logs.openstack.org/16/427916/1/check/gate-grenade-dsvm-neutron-ubuntu-xenial/56b7a7d/logs/grenade.sh.txt.gz#_2017-02-08_13_48_54_600

[Dolph Mathews (dolph)]

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.

[Lance Bragstad (lbragstad)]

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

[Doug Hellmann (doug-hellmann)]

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.

[Sean Dague (sdague)]

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.

[Lance Bragstad (lbragstad)]

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?

[Graham Hayes (grahamhayes)]

This is now blocking the designate gates.

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

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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

[David Stanek (dstanek)]

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.

[Lance Bragstad (lbragstad)]

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.