<div dir="ltr">This was entirely intentional, in order to replace the implicit role assignment behavior in v2 with an explicit behavior in v3.<div><br></div><div>The default_project_id attribute (***emphasis*** mine):</div><div><br></div><div>> 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.</div><div><br></div><div>> 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.<br></div><div><br></div><div>Source: <a href="https://github.com/openstack/keystone-specs/blob/master/api/v3/identity-api-v3.rst#users-v3users">https://github.com/openstack/keystone-specs/blob/master/api/v3/identity-api-v3.rst#users-v3users</a></div><div><br></div><div>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.</div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 18, 2015 at 8:25 AM, Rich Megginson <span dir="ltr"><<a href="mailto:rmeggins@redhat.com" target="_blank">rmeggins@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<div>On 06/18/2015 06:43 AM, Raildo Mascena
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi Rick,<br>
<br>
<div>In Keystone, Domains are the container of users, so a user
belongs to a domain and you can grant role assignments for
projects.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>So, you can do:<b> openstack role add --user USER_NAME
--project TENANT_ID ROLE_NAME</b></div>
<div><b><br>
</b></div>
<div>and after that, you can verify if the assignment works
doing:<b> openstack role list --user USER_NAME --projec
TENANT_ID</b></div>
<div><b><br>
</b></div>
<div>You can find more information about this here:<b> </b><a href="http://docs.openstack.org/user-guide-admin/manage_projects_users_and_roles.html" target="_blank">http://docs.openstack.org/user-guide-admin/manage_projects_users_and_roles.html</a> or
find us on #openstack-keystone</div>
</div>
</blockquote>
<br></span>
Yes, I realize that.<br>
<br>
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.<br>
<br>
<a href="https://review.openstack.org/#/c/174976/24/lib/puppet/provider/keystone_user/openstack.rb" target="_blank">https://review.openstack.org/#/c/174976/24/lib/puppet/provider/keystone_user/openstack.rb</a><div><div class="h5"><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Cheers,</div>
<div><br>
</div>
<div>Raildo Mascena</div>
<div><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Tue, Jun 16, 2015 at 1:52 PM Rich Megginson
<<a href="mailto:rmeggins@redhat.com" target="_blank">rmeggins@redhat.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Using
admin token credentials with the Keystone v2.0 API and the<br>
openstackclient, doing this:<br>
<br>
# openstack project create bar --enable<br>
# openstack user create foo --project bar --enable ...<br>
<br>
The user will be added to the project.<br>
<br>
Using admin token credentials with the Keystone v3 API and
the<br>
openstackclient, using the v3 policy file with is_admin:1
added just<br>
about everywhere, doing this:<br>
<br>
# openstack project create bar --domain Default --enable<br>
# openstack user create foo --domain Default --enable
--project<br>
$project_id_of_bar ...<br>
<br>
The user will NOT be added to the project.<br>
<br>
Is this intentional? Am I missing some sort of policy to
allow user<br>
create to add the user to the given project?<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div></div>