<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 17, 2014 at 5:43 AM, McCabe, Donagh <span dir="ltr"><<a href="mailto:Donagh.McCabe@hp.com" target="_blank">Donagh.McCabe@hp.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 lang="EN-GB" link="#0563C1" vlink="#954F72">
<div>
<p>Hi,<u></u><u></u></p>
<p><u></u> <u></u></p>
<p>I’m working on the Swift implications of using composite authorization [1] [2].<u></u><u></u></p>
<p><u></u> <u></u></p>
<p>My question for Keystone developers is : what  project-id do we expect the service token to be scoped to - the service's project or the end-user's project? When reviewing the Keystone spec, I had assumed the former. However, now that
 I'm looking at it in more detail, I would like to check my understanding.</p></div></div></blockquote><div>FWIW, prior to reading the below, I would have said I don't think it should matter to Swift. The project in the primary X-Auth-Token (rather than the secondary X-Service-Token) should be the one that conveys the scope. But... I'm probably wrong, and I think I prefer option 2 below.<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"><div lang="EN-GB" link="#0563C1" vlink="#954F72"><div>

<p><u></u><u></u></p>
<p><u></u> <u></u></p>
<p>The implications are:<u></u><u></u></p>
<p><u></u> <u></u></p>
<p>1/ If scoped to the service's project, the role used must be exclusive to Glance/Cinder.</p></div></div></blockquote><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 lang="EN-GB" link="#0563C1" vlink="#954F72"><div><p>I.e. an end-user must never be assigned this role.</p></div></div></blockquote><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 lang="EN-GB" link="#0563C1" vlink="#954F72"><div><p>In effect, a role on one project grants the service user some privileges on every project.</p></div></div></blockquote><div>Keystone would never make this last behavior ^ explicit, without hierarchical multitenancy (and a single root project)... because we already have the solution I describe below...</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"><div lang="EN-GB" link="#0563C1" vlink="#954F72"><div><p>
<u></u><u></u></p>

<p><u></u> <u></u></p>
<p>2/ if scoped to the end-user's project, the glance/cinder service user must have a role on every project that uses them (including across domains); this seems infeasible.</p></div></div></blockquote><div>Keystone does have domain-level role assignments that are inherited to projects... so a service could be assigned a role on a domain with inheritance, and then the service can generate project-scoped tokens (with the domain-level role applied) for any project in the domain. I think that would make option 2 much more feasible, but yes- you still need a role assignment for per domain in the system.<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"><div lang="EN-GB" link="#0563C1" vlink="#954F72"><div>

<p>
<u></u><u></u></p>
<p><u></u> <u></u></p>
<p>Regards,<u></u><u></u></p>
<p>Donagh<u></u><u></u></p>
<p><u></u> <u></u></p>
<p>[1] swift-specs: <a href="https://review.openstack.org/105228" target="_blank">
https://review.openstack.org/105228</a><u></u><u></u></p>
<p class="MsoNormal">[2] keystone-specs: <a href="https://review.openstack.org/#/c/96315/" target="_blank">
https://review.openstack.org/#/c/96315/</a><u></u><u></u></p>
</div>
</div>

<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<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><br>
<br></blockquote></div><br></div></div>