<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><div><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></div></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><div>
<br></div>Also, should we be updating the Nova policy code to be able to handle domains?</div></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> </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 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">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>