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). Thanks. [1] https://github.com/openstack/keystone/blob/master/keystone/auth/plugins/mapped.py#L37 On Thu, Dec 7, 2017 at 7: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? > > Best regards, > -- > Dr. Pavlo Shchelokovskyy > Senior Software Engineer > Mirantis Inc > www.mirantis.com > > __________________________________________________________________________ > 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 > >
__________________________________________________________________________ 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