User create via v3 API doesn't add _member_ role in default project

[Steven Hardy]

There is a discrepancy between creating users via the v2 and v3 API's, which I'm not sure is a bug or by design:

When creating a user via the v2 API, the _member_ role is added in their default project, but when creating via the v3 API, despite default_project_id being specified, it is not.

If possible, I'd like the _member_ role to always be present, as we need a default role to delegate via trust for heat, and I'd like to move away from using a special heat_stack_owner role as it's confusing for users:

https://review.openstack.org/#/c/119415/

-bash-4.2$ openstack --os-token foobar --os-url=http://127.0.0.1:5000/v3 --os-identity-api-version=3 user create --domain Default --project demo test123456
+--------------------+---------------------------------------------------------------------------------+
| Field | Value |
+--------------------+---------------------------------------------------------------------------------+
| default_project_id | 19d521c102844134b4c141af967d75fd |
| domain_id | default |
| enabled | True |
| id | 479882b84fed407a9bc5a95778aba85e |
| links | {u'self': u'http://192.168.0.4:5000/v3/users/479882b84fed407a9bc5a95778aba85e'} |
| name | test123456 |
+--------------------+---------------------------------------------------------------------------------+
-bash-4.2$ keystone user-create --tenant demo --name v2test123456
+----------+----------------------------------+
| Property | Value |
+----------+----------------------------------+
| email | |
| enabled | True |
| id | c8d14d95bec24a56b0414b41b94a9e4e |
| name | v2test123456 |
| tenantId | 19d521c102844134b4c141af967d75fd |
| username | v2test123456 |
+----------+----------------------------------+
-bash-4.2$ keystone user-role-list --tenant demo --user test123456

-bash-4.2$ keystone user-role-list --tenant demo --user v2test123456
+----------------------------------+----------+----------------------------------+----------------------------------+
| id | name | user_id | tenant_id |
+----------------------------------+----------+----------------------------------+----------------------------------+
| 9fe2ff9ee4384b1894a90878d3e92bab | _member_ | c8d14d95bec24a56b0414b41b94a9e4e | 19d521c102844134b4c141af967d75fd |
+----------------------------------+----------+----------------------------------+----------------------------------+

[Lance Bragstad (lbragstad)]

According to the Identity V3 API specification, the default_project_id attribute of the user object is simply there for reference to the user.

https://github.com/openstack/identity-api/blob/master/v3/src/markdown/identity-api-v3.md#users-v3users

It also says that setting default_project_id does not actually grant authorization on the project, in which case I don't think the user would need a role assigned for that project by default on create user operations.

Thoughts?

[Steven Hardy (shardy)]

@Lance: Thanks, I had a feeling that may be the case but was seeking clarification, clearly I missed that detail in the docs.

I'm a little uncertain what the point of a user having a default project at all, if default_project_id is essentially not granting them any access to that project?

Really, I'm trying to get a handle on what the expected migration strategy from v2 to v3 will be, e.g if "_member_" will remain a valid default role for heat to expect all users to have (e.g so we can delegate it to the heat service via trusts in all cases, without the user/operator inconvenience of a heat-specific role unless they choose it).

Am I right in assuming the expected workflow for v3 will be:

1. Create new user
2. Grant user _member_ to all projects they have access to, including default_project_id

IMHO the default_project_id does nothing thing is suboptimal, and will cause unnecessary friction for folks migrating from v2 - I guess there's a reason why it's been done that way though, any links to historical discussions which may help me understand that?

Thanks again for the assistance.

[Henry Nash (henry-nash)]

So for v3, it was decided that default_project should simply be a short cut to allow a user to not have to specify a scope as part of an auth request...if they don't, the token will be scoped to the default project. The can override this, of course, by specifying an explicit scope in the auth request. As has been discussed, the difference between v2 and v3 is that in v2 the act of assigning a default project to a user would also (effectively) create a role assignment for the user to the project in question. In v3, this step is required as a manual step, ahead of authentication.

[Dolph Mathews (dolph)]

As described above, this is by design. Granting authorization in v3 is more explicit than in v2.