On Mon, Sep 30, 2013 at 11:42 PM, Christopher Yeoh <cbky...@gmail.com>wrote:
> Hi, > > 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. > > 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? > 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. > > Also, should we be updating the Nova policy code to be able to handle > domains? > 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. 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). > > > Regards, > > Chris > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- -Dolph
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev