<div dir="ltr"><br>Thanks Henry and Dolph - I think I understand how it could all<br>fit together now.<br><br>Regards,<br><br>Chris<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Oct 1, 2013 at 4:17 PM, 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"><div style="word-wrap:break-word">I think an obvious first step of domain support outside keystone is for images.  Today, I believe, an image can be global or project based.  There is definitely a use case for a third state of being domain based - and hence available to all projects in that domain, but not to those in other domains.<div>
<br></div><div>From a Nova perspective, where domains might be relevant is in how a cloud provider divides up their infrastructure, for example, I think there are use cases for when a cloud provider might want to specify on a domain-basis:</div>
<div>- availability zones and/or host aggregates</div><div>- quotas</div><div>- IP ranges (ok, maybe a quantum discussion)</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Henry</div></font></span><div>
<div class="h5"><div><div><div>On 1 Oct 2013, at 06:45, Dolph Mathews <<a href="mailto:dolph.mathews@gmail.com" target="_blank">dolph.mathews@gmail.com</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr"><br>
<div class="gmail_extra"><div class="gmail_quote">On Mon, Sep 30, 2013 at 11:42 PM, Christopher Yeoh <span dir="ltr"><<a href="mailto:cbkyeoh@gmail.com" target="_blank">cbkyeoh@gmail.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 dir="ltr"><div>Hi,<br><br>I've been looking into how Nova might support Keystone V3 domains and I'm having a bit of trouble getting my head around exactly how we'd use domain scoped tokens.<br>

<br>
</div>With the V3 Nova API we no longer specify the tenant id in the url as it is implicit in the token used to authorize with. This is true for Keystone V3  tenant scoped tokens, but not for domain scoped tokens.  If we're going to use domain scoped tokens with the Nova API is the idea that a client would pass the tenant id in a header as well as the domain scoped token and Nova would check that the tenant passed belongs to the domain that is implicit with the token?<br>

</div></blockquote><div><br></div><div>Without a specific use case to support domain-based operations, I'd be opposed to handling this scenario "implicitly." I have yet to hear a use case for domain awareness in nova, so I'd expect nova to return a 401 for any domain-based token.</div>

<div> <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 dir="ltr"><div>
<br></div>Also, should we be updating the Nova policy code to be able to handle domains?</div></blockquote><div><br></div><div>Keystone supports domain-based authorization on two levels: domain-specific role assignments and domain-specific role assignments that are inherited to all projects/tenants owned by that domain.</div>

<div><br></div><div>With inheritance, a domain administrator can request authorization on any project in the domain (from keystone, per usual) and nova's policy doesn't have to handle anything special (it'll just be a regular project/tenant scoped token).</div>

<div> </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 dir="ltr"> </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 dir="ltr"><div><br></div>Regards,<br><br>Chris<br><br>

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