Open Stack

This was entirely intentional, in order to replace the implicit role
assignment behavior in v2 with an explicit behavior in v3.

The default_project_id attribute (***emphasis*** mine):

> References the user's default project against which to authorize, if the
API user does not explicitly specify one when creating a token. ***Setting
this attribute does not grant any actual authorization on the project,***
and is merely provided for the user's convenience. Therefore, the
referenced project does not need to exist within the user's domain.

> New in version 3.1 If the user does not have authorization to their
default project, the default project will be ignored at token creation.

Source:
https://github.com/openstack/keystone-specs/blob/master/api/v3/identity-api-v3.rst#users-v3users

In fact, since Grizzly, Keystone has *explicitly* assigned a role (_member_
by default) to users behind the scenes when you try to *implicitly* give
them authorization using the v2 user.tenant_id attribute. Prior to the new,
more explicit behaviors, default tenancy could not be consumed by RBAC
policy engines, because there was nothing explicit about the relationship.

On Thu, Jun 18, 2015 at 8:25 AM, Rich Megginson <rmeggins at redhat.com> wrote:

>  On 06/18/2015 06:43 AM, Raildo Mascena wrote:
>
> Hi Rick,
>
> In Keystone, Domains are the container of users, so a user belongs to a
> domain and you can grant role assignments for projects.
>
>  With this call that you made, you will set the project default to this
> user, after that you need to grant a role for this user in this project.
>
>  So, you can do:* openstack role add --user USER_NAME --project TENANT_ID
> ROLE_NAME*
>
>  and after that, you can verify if the assignment works doing:* openstack
> role list --user USER_NAME --projec TENANT_ID*
>
>  You can find more information about this here:
> http://docs.openstack.org/user-guide-admin/manage_projects_users_and_roles.html or
> find us on #openstack-keystone
>
>
> Yes, I realize that.
>
> My issue was that in going from Keystone v2.0 to v3, openstack user create
> --project $project changed behavior - in v2.0, openstack user create
> --project $project adds the user as a member of the $project.  I wanted to
> know if this was 1) intentional behavior in v2.0 2) intentionally removed
> in v3.  I'm trying to make puppet-keystone work with v3, while at the same
> time making sure all of the existing puppet manifests work exactly as
> before.  Since this has changed, I had to work around it, by making the
> puppet-keystone user create function also add the user to the project.
>
>
> https://review.openstack.org/#/c/174976/24/lib/puppet/provider/keystone_user/openstack.rb
>
>
>
>  Cheers,
>
>  Raildo Mascena
>
>
>  On Tue, Jun 16, 2015 at 1:52 PM Rich Megginson <rmeggins at redhat.com>
> wrote:
>
>> Using admin token credentials with the Keystone v2.0 API and the
>> openstackclient, doing this:
>>
>> # openstack project create bar --enable
>> # openstack user create foo --project bar --enable ...
>>
>> The user will be added to the project.
>>
>> Using admin token credentials with the Keystone v3 API and the
>> openstackclient, using the v3 policy file with is_admin:1 added just
>> about everywhere, doing this:
>>
>> # openstack project create bar --domain Default --enable
>> # openstack user create foo --domain Default --enable --project
>> $project_id_of_bar ...
>>
>> The user will NOT be added to the project.
>>
>> Is this intentional?  Am I missing some sort of policy to allow user
>> create to add the user to the given project?
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150618/209c5ce5/attachment.html>