Hi, > On 12/07/2017 12:27 PM, Colleen Murphy wrote: >> On Thu, Dec 7, 2017 at 5:37 PM, Pavlo Shchelokovskyy >> <pshchelokovs...@mirantis.com> wrote: >>> Hi all, >>> >>> We have a following use case - several independent keystones (say KeyA and >>> KeyB), using fernet tokens and synchronized fernet keys, and single external >>> IdP for federated auth. >>> >>> Is it generally possible to configure both KeyA and KeyB such that scoped >>> token issued by KeyA for a federated user is valid on KeyB? >>> >>> Currently we have the next problem - although domains/projects where >>> keystone's mapping engine assigns federated users are equal by name between >>> KeyA and KeyB, the UUIDs of projects/domains in KeyA and KeyB are >>> different, which seems to invalidate the scoped token issued by KeyA when >>> trying to use it for KeyB. And it is not possible to create projects/domains >>> with specific UUIDs via keystone API (which would probably solve this >>> problem for non-autoprovisioned projects). >>> >>> Is such usage scenario supported? Or one should always use the unscoped >>> token first to list projects/domains available on a specific keystone >>> instance and then get a scoped token for usage o this instance only? >> No, it is not currently possible to use the same token on projects in >> different keystones, for the reasons you gave. You might be interested >> in following https://review.openstack.org/#/c/323499/ if you're not >> already aware of it, which has the goal of solving that problem. >> >> It's also been brought up before: >> >> https://review.openstack.org/#/c/403866/ >> http://lists.openstack.org/pipermail/openstack-dev/2016-December/108466.html >> >> And we talked about it a lot at the last Forum (sorry my brief summary >> does not really do the discussion justice): >> >> http://www.gazlene.net/sydney-summit.html#keystone-operator-and-user-feedback > I had a snippet about it in my recap under the "Other Feedback" section > [0]. The TL;DR in my opinion is that we originally thought we could > solve the problem with federation 100%, and if we couldn't we wanted to > try and improve the parts of federation that would make that possible. > > The interesting bit we came up with during the feedback session in > Sydney is what happens if a user no longer has a role on a project. For > example; > > - A user has a role on Project A and in the us-east region and the > us-west region, each region has it's own keystone deployment, but let's > assume the ID for Project A are the same in each region > - A user authenticates for a token scoped to Project A and starts > creating instances in both regions > - The user has their role from Project A removed in us-east, but not in > us-west > - The user isn't able to do anything within us-east since they no longer > have a role assignment on Project A in that region, but they can still > take the invalid token from the us-east region and effectively use it in > the us-west region > > Without replicating revocation events, or syncing the assignment table, > this will lead to security concerns.
There is also cache invalidation issue. And that would make tokens of various scope behave in a different manner. A year ago i was -2 on this, and i still don't think this is a good idea. If there is a demand to control several clouds from single place, K2K support should be added where it is needed.
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev