Open Stack

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?

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).

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.


-Dolph


On Thu, Nov 29, 2012 at 2:21 AM, Henry Nash <henryn at linux.vnet.ibm.com>wrote:

> Hi
>
> 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 :
> https://blueprints.launchpad.net/keystone/+spec/domain-scoping).
>
> 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?
>
> 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.
>
> Henry
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121129/645bafe5/attachment.html>