Open Stack

On Mon, Sep 30, 2013 at 11:42 PM, Christopher Yeoh <cbkyeoh at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

-Dolph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131001/c148c59a/attachment.html>