cbcccb9eca
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
12 lines
555 B
YAML
12 lines
555 B
YAML
---
|
|
fixes:
|
|
- |
|
|
A Federated user gets an entry in the shadow-users table. This
|
|
entry has a unique ID. It was generated using a UUID. This fix
|
|
changes to reuse the mechanism for LDAP, where the ID is generated
|
|
from the domain ID + the local id of the user (an attribute that
|
|
uniquely ids the user from the IdP). This generator is specified
|
|
by the configuration file. Now Both LDAP and Federated Ids are
|
|
generated the same way. It also means that Federated IDs can be
|
|
kept in sync between two independtent Keystone servers.
|