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

keystone/identity/shadow_backends/sql.py

@@ -13,11 +13,11 @@
 import copy
 import datetime
 import sqlalchemy
-import uuid
 
 from oslo_config import cfg
 from oslo_db import api as oslo_db_api
 
+from keystone.common import provider_api
 from keystone.common import sql
 from keystone import exception
 from keystone.identity.backends import base as identity_base
@@ -26,13 +26,21 @@ from keystone.identity.shadow_backends import base
 
 
 CONF = cfg.CONF
+PROVIDERS = provider_api.ProviderAPIs
 
 
 class ShadowUsers(base.ShadowUsersDriverBase):
     @sql.handle_conflicts(conflict_type='federated_user')
     def create_federated_user(self, domain_id, federated_dict, email=None):
+
+        local_entity = {'domain_id': domain_id,
+                        'local_id': federated_dict['unique_id'],
+                        'entity_type': 'user'}
+
+        public_id = PROVIDERS.id_generator_api.generate_public_ID(local_entity)
+
         user = {
-            'id': uuid.uuid4().hex,
+            'id': public_id,
             'domain_id': domain_id,
             'enabled': True
         }

releasenotes/notes/bug-1641639-b9accc163e61ca15.yaml

@@ -0,0 +1,11 @@
+---
+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.