Open Stack

On Thu, Jul 17, 2014 at 5:43 AM, McCabe, Donagh <Donagh.McCabe at hp.com>
wrote:

>  Hi,
>
>
>
> I’m working on the Swift implications of using composite authorization [1]
> [2].
>
>
>
> My question for Keystone developers is : what  project-id do we expect the
> service token to be scoped to - the service's project or the end-user's
> project? When reviewing the Keystone spec, I had assumed the former.
> However, now that I'm looking at it in more detail, I would like to check
> my understanding.
>
FWIW, prior to reading the below, I would have said I don't think it should
matter to Swift. The project in the primary X-Auth-Token (rather than the
secondary X-Service-Token) should be the one that conveys the scope. But...
I'm probably wrong, and I think I prefer option 2 below.

>
>
> The implications are:
>
>
>
> 1/ If scoped to the service's project, the role used must be exclusive to
> Glance/Cinder.
>
I.e. an end-user must never be assigned this role.
>
In effect, a role on one project grants the service user some privileges on
> every project.
>
Keystone would never make this last behavior ^ explicit, without
hierarchical multitenancy (and a single root project)... because we already
have the solution I describe below...

>
>
> 2/ if scoped to the end-user's project, the glance/cinder service user
> must have a role on every project that uses them (including across
> domains); this seems infeasible.
>
Keystone does have domain-level role assignments that are inherited to
projects... so a service could be assigned a role on a domain with
inheritance, and then the service can generate project-scoped tokens (with
the domain-level role applied) for any project in the domain. I think that
would make option 2 much more feasible, but yes- you still need a role
assignment for per domain in the system.

>
>
> Regards,
>
> Donagh
>
>
>
> [1] swift-specs: https://review.openstack.org/105228
>
> [2] keystone-specs: https://review.openstack.org/#/c/96315/
>
> _______________________________________________
> 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/20140717/987e428c/attachment.html>