use mapping_id for shadow users

[Steve Martinelli]

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)]

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)]

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

[Steve Martinelli (stevemar)]

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.

[1] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ocata/shadow-mapping.html
[2] http://specs.openstack.org/openstack/keystone-specs/specs/mitaka/shadow-users.html

[Robert Duncan (rduncan-t)]

thanks Steve,

I was havin' a bad day!

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/623117

[OpenStack Infra (hudson-openstack)]

Change abandoned by ayoung (<email address hidden>) on branch: master
Review: https://review.openstack.org/623117

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/605169
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=cbcccb9ecadc37d45a66b87cd80e2fd7ee3de3f7
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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/650615
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=44c1b3d28407b66d2a854105f210d53f7cdd6b6f
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

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/keystone 16.0.0.0rc1 release candidate.