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

Кирилл Беспалов k.besplv at gmail.com
Thu Dec 7 18:23:55 UTC 2017

Hi, Pavlo.

Looks like it's not just project/domain UUID should be equal, but also
audit_id, endpoints_id, protocol_id, roles_id and many other entities.
So, looks like it is not possible to implement this using current code
base, but I could be wrong.

You can take a look at mapped auth plugin [1] in order to investigate what
exactly should be the same (ids).



On Thu, Dec 7, 2017 at 7: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?
> Best regards,
> --
> Dr. Pavlo Shchelokovskyy
> Senior Software Engineer
> Mirantis Inc
> www.mirantis.com
> __________________________________________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171207/c0105524/attachment.html>

More information about the OpenStack-dev mailing list