use mapping_id for shadow users

Bug #1641639 reported by Steve Martinelli on 2016-11-14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Adam Young

Bug Description

Currently, shadow users are created for users that log in through federation. New "local_user" accounts are created with a new UUID. Rather than creating a new UUID, we should re-use the mapping_id backend that was employed with LDAP users.

Lance Bragstad (lbragstad) wrote :

With the existing mapping backend, would it be possible to still get random UUIDs? At that point, is the mapping_id backend a mapping backend anymore? Would it make more sense for it to be just a thing that supplies IDs?

Robert Duncan (rduncan-t) wrote :

Why are federated users becoming keystone users? - why is all the mapping being handled at the service provider? - why can't we just pass ROLE_ID = as part of the security assertion? - all this mapping has to happen at the identity provider anyway!! we don't let every ldap user into openstack. - operators are scratching heads! - overly difficult for simple RBAC

Changed in keystone:
milestone: ocata-2 → none
Steve Martinelli (stevemar) wrote :

Hi Robert,

Thanks for your feedback. The shadow mapping feature [1] should actually ease some of the issues you mentioned, in particular around just passing in role ID. With shadow mapping you should be able to specify role and project information for a federated user. It's being implemented for Ocata.

We decided to persist the federated users into the keystone SQL backend for various reasons [2]:
  - support notifications better, the user ID will be the same
  - more consistent interface with other user APIs
  - support account linking in the future
  - support multi-factor auth in the future
  - support linking domains and identity providers (this is necessary for federated users to use heat or murano)
This was implemented in Mitaka.

This bug is being used as a suggestion to use the same ID tracking mechanism we use with LDAP users, for federated users.


Changed in keystone:
importance: Medium → Wishlist
Robert Duncan (rduncan-t) wrote :

thanks Steve,

I was havin' a bad day!

Changed in keystone:
assignee: nobody → Adam Young (ayoung)
status: Confirmed → In Progress

Change abandoned by ayoung (<email address hidden>) on branch: master

Submitter: Zuul
Branch: master

commit cbcccb9ecadc37d45a66b87cd80e2fd7ee3de3f7
Author: Adam Young <email address hidden>
Date: Tue Sep 25 14:17:28 2018 -0400

    Replace UUID with id_generator for Federated users

    The LDAP code has long had a swappable backend to generate
    the user IDs that map from LDAP to SQL. THe Federated code
    was supposed to use the same mechanism, but it ended up
    generating a UUID for the userid instead. This is a backwards
    compatible change that converts the Federated UserIDs to a
    sha256 hash of the same 3 pieces of data that LDAP now uses:
    the domain_id, the unique ID from the Federated backend, and
    the entity type (User).

    This code is tested via
    tox -e py35 -- keystone.tests.unit.test_shadow_users

    Longer IDs show up in some of the Federation tests

    closes-bug: 1641639

    Change-Id: Ica21c54c1fcc9b44e4935718c8903237d0857120

Changed in keystone:
status: In Progress → Fix Released

Submitter: Zuul
Branch: master

commit 44c1b3d28407b66d2a854105f210d53f7cdd6b6f
Author: Colleen Murphy <email address hidden>
Date: Sun Apr 7 23:19:47 2019 -0700

    Convert user_id back to string

    Now that the user ID for shadowed, federated users is no longer a random
    UUID but a sha256 hash, the token formatter shouldn't be trying to
    convert it to a byte string, and yet on python3 msgpack does anyway, so
    we need to convert it back to a string.

    Related-bug: #1641639

    Change-Id: Icb2a591642df96d5bbd02428d2b0d0e8090009c0

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers