On Thu, Jul 17, 2014 at 5:43 AM, McCabe, Donagh <[email protected]> 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
