<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div></div><div>I appreciate that we have not yet agreed the items in red, but it appears logical to me that we will need them. The question is how would we provide authorization backbone for this? One option is domain scoping would not apply to children of sub-containers like projects (i.e. getting a token to a domain does NOT authorize you to manipulate the projects). So projects would not be returned in this case....and a project-scoped token would have to be obtained later to work on a project. Clearly some more discussion required here. In fact, conceptually you might say that some of the project CRUD in Keystone should be done with a domain scoped token...but I know that we don't use this model in keystone). </div><div><br></div><div>Our challenge is to balance the above model, with the current one where a cloud provider wanting to host individuals or SMEs by not using domains (except one big common domain) and each "customer" just gets a project to work in. Do we want to continue to recommend this as a model - or actually, is the recommended model always to create a domain with minimally one project in it? While that is conceptually nice, maybe too much overhead.</div><div><br></div><div>Henry</div><div><div><div>On 29 Nov 2012, at 13:59, Dolph Mathews wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">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>
_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br></blockquote></div><br></div></body></html>