Are you expecting other services to accept a token "scoped to a domain" as having authorization to perform operations on a specific tenant in that domain?<div><br></div><div>If so, this either forces every service to become aware of keystone domains (and look up their containing tenants), or for keystone to return a potentially massive list of tenants as part of the token (making PKI tokens enormous).</div>
<div><br></div><div>If not, it seems like a mechanism to provide in conjunction with role grants across domains, in order to produce/exchange tokens for more narrowly scoped tokens... but as a user, I'd be confused when the auth_token middleware rejected such a broadly scoped token.</div>
<div class="gmail_extra"><br clear="all"><div><br></div>-Dolph<br>
<br><br><div class="gmail_quote">On Thu, Nov 29, 2012 at 2:21 AM, Henry Nash <span dir="ltr"><<a href="mailto:henryn@linux.vnet.ibm.com" target="_blank">henryn@linux.vnet.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi<br>
<br>
One of the requests from the summit was for allowing the scoping of a token to multiple projects, and this is being worked on for Grizzly.  However, I would like us to re-visit (or maybe just re-clarify) this requirement - whilst also considering the option of scoping to a domain (see blueprint at : <a href="https://blueprints.launchpad.net/keystone/+spec/domain-scoping" target="_blank">https://blueprints.launchpad.net/keystone/+spec/domain-scoping</a>).<br>

<br>
Now the whole point of scoping to anything, is to make it possible (and in some cases easier) to execute operations on the granularity that you have "scoped to". It seems to me that now we have a domain as the logical container for users and projects, clearly one of the common usages will be operations that want to look at all the projects (or some aspect of projects) in a domain - hence the idea of scoping to a domain.  This would provide a somewhat simpler, both request & response, than an appropriately scoped token than an arbitrary list of projects (where you end up returning a nested set of projects and their domains in the response, for example).  Further, if we had this, would we really need the ability to scope to multiple projects from different domains (which is technically the request on the table right now)?  Remember, scoping is defining the access rights - just allowing a suitable granularity of scope for upcoming operations - so you only really need a complex scope if the you have some operation that needs to carried out across that complex set of objects.  Are there such a set of operations that people have in mind?<br>

<br>
I raise this so that we just look at whether there is some simplification to the expansion of ability to scoping, before we go too far.<br>
<br>
Henry<br>
<br>
<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>
</blockquote></div><br></div>