[openstack-dev] [keystone] multiple federated keystones with single Identity Provider

Adam Heczko aheczko at mirantis.com
Fri Dec 8 09:28:02 UTC 2017

Hi Pavlo, I think that there are viable alternatives to your specific use
case having single external idp for federated auth.
Depending on your IT environment architecture and preferences you have the
following possibilities, both of them are providing very smooth user
- in AD centric environments connect each of Keystone services to AD and
leverage Kerberos for SSO. You can consume REMOTE_USER and other variables
from AD directly via mod_auth_gssapi and mod_lookup_identity. Advantage of
this approach is that you can leverage AD native SSO mechanism based on
SPNEGO. So you are not any longer  forcing users to perform SAML or OIDC
referrals etc.
- in both AD or non AD centric environments you can leverage 'Tokenless
Auth' plugin, which basically can also be used with Keystone to issue
tokens (e.g. Fernet) and perform token scoping based on X.509 certificate
properties. You can also configure specific X.509 certificate attributes
e.g. SAN or subjectDirectoryAttributes to control access for specific
region or Keystone instance.

On Fri, Dec 8, 2017 at 1:25 AM, Boris Bobrov <breton at cynicmansion.ru> wrote:

> Hi,
> > On 12/07/2017 12:27 PM, Colleen Murphy wrote:
> >> On Thu, Dec 7, 2017 at 5:37 PM, Pavlo Shchelokovskyy
> >> <pshchelokovskyy at 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.
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Adam Heczko
Security Engineer @ Mirantis Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171208/2fecba7e/attachment.html>

More information about the OpenStack-dev mailing list