<div dir="ltr">I don't see that we need a new 
role for this because it would need to be added to all the admin users. I
 was thinking just admin or target.project_id==token.project_id. 
Hopefully in future this would get better because we can get nova to 
send the service token as well and enforce that it came from another 
service as well. </div><div class="gmail_extra"><br><div class="gmail_quote">On 6 May 2016 at 07:54, Dolph Mathews <span dir="ltr"><<a href="mailto:dolph.mathews@gmail.com" target="_blank">dolph.mathews@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">My understanding from the summit session was that we should have a specific role defined in keystone's policy.json here:<div><br></div><div>  <a href="https://github.com/openstack/keystone/blob/a16287af5b7761c8453b2a8e278d78652497377c/etc/policy.json#L37" target="_blank">https://github.com/openstack/keystone/blob/a16287af5b7761c8453b2a8e278d78652497377c/etc/policy.json#L37</a></div><div><br></div><div>Which grants access to nothing in keystone beyond that check. So, the new rule could be revised to something as generic as:</div><div><br></div><div>  "identity:get_project": "rule:admin_required or project_id:%(<a href="http://target.project.id" target="_blank">target.project.id</a>)s or role:identity_get_project",</div><div><br></div><div>Where the new role name I appended at the end exactly matches the policy rule name.</div><div><br></div><div>However, unlike the summit discussion, which specified only providing access to HEAD /v3/projects/{project_id}, keystone's usage of policy unfortunately wraps both HEAD and GET with the same policy check.</div></div><div class="HOEnZb"><div class="h5"><br><div class="gmail_quote"><div dir="ltr">On Thu, May 5, 2016 at 3:05 PM Augustina Ragwitz <<a href="mailto:aragwitz.lists@pobox.com" target="_blank">aragwitz.lists@pobox.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm currently working on the spec for Project ID Validation in Nova<br>
using Keystone. The outcome of the Design Summit Session was that the<br>
Nova service user would use the Keystone policy to establish whether the<br>
requester had access to the project at all to verify the id. I was<br>
wondering if there were any code examples of a non-Keystone service<br>
using the Keystone policy in this way?<br>
<br>
Also if I misunderstood something, please feel free to correct me or to<br>
clarify!<br>
<br>
Here is the etherpad from the session:<br>
<a href="https://etherpad.openstack.org/p/newton-nova-keystone" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/newton-nova-keystone</a><br>
And here is the current spec: <a href="https://review.openstack.org/#/c/294337" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/294337</a><br>
<br>
<br>
--<br>
Augustina Ragwitz<br>
Sr Systems Software Engineer, HPE Cloud<br>
Hewlett Packard Enterprise<br>
---<br>
irc: auggy<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></div><span class="HOEnZb"><font color="#888888"><div dir="ltr">-- <br></div><div dir="ltr">-Dolph</div>
</font></span><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>