From c54a16fd19fd984f8cfe6eb3367c5aa0d872e314 Mon Sep 17 00:00:00 2001 From: Lance Bragstad Date: Mon, 22 Oct 2018 21:47:28 +0000 Subject: [PATCH] Clean up explicit domain IDs specification Change-Id: I685e8aff8deda7a2bb6563989bf62252ecf05f25 --- specs/keystone/stein/explicit-domains-ids.rst | 38 ++++++++----------- 1 file changed, 16 insertions(+), 22 deletions(-) diff --git a/specs/keystone/stein/explicit-domains-ids.rst b/specs/keystone/stein/explicit-domains-ids.rst index 6f9ff211..3eb88ccc 100644 --- a/specs/keystone/stein/explicit-domains-ids.rst +++ b/specs/keystone/stein/explicit-domains-ids.rst @@ -10,7 +10,6 @@ Explicit Domain IDs `Explicit Domain IDs `_ - Problem Description =================== @@ -29,14 +28,14 @@ multiple deployments then has to correlate the user IDs across different Keystone servers. To avoid this, operators want to keep the LDAP users in a domain with -a consistant ID across deployments. The only domain with a -predictable ID, however, is `default.` THe default domain is used -during the initial install, and thus has service users. Thus, it is -inpractical to put the LDAP users in the default domain. If a site +a consistent ID across deployments. The only domain with a +predictable ID, however, is `default.` Tee default domain is used +during the initial install, and thus has service users. Thus, it is +impractical to put the LDAP users in the default domain. If a site wished to have two LDAP servers in domain specific backends, only one could be put in default. -Today, if a depoloyer desires to keep two Keystone servers in sync +Today, if a deployer desires to keep two Keystone servers in sync while avoiding Database replication, they must hack the database to update the Domain ID so that entries match. Domain ID is then used for LDAP mapped IDs, and if they don't match, the user IDs are @@ -44,10 +43,10 @@ different. It should be possible to add a domain with an explicit ID, so that the two servers can match User IDs. An additional effort is underway to make the Federated Identity -sources use the same mechanism as LDAP. This effort is hampered +sources use the same mechanism as LDAP. This effort is hampered by the same domain_id restrictions as LDAP. -Making the identifiers consistant across multiple deployments will aid +Making the identifiers consistent across multiple deployments will aid in several use cases: It will make it easier to synchronize role assignments across two @@ -55,32 +54,31 @@ distinct deployments, as the user ID from the first can be used in the second. Applications will now be able to predict what user-id a user would -have in a cluster, even before that user visits the cluster. This +have in a cluster, even before that user visits the cluster. This allows the system to pre-create user records, and have them link to the identity source when the user does finally authenticate to the Keystone server. -One structure that can be used for multiple depoloyments is for each +One structure that can be used for multiple deployments is for each Keystone server to represent a different region, and for each region -to have a set of domains for which it is the system of record. This -allows local writes and avoids conflicts. In order for a central +to have a set of domains for which it is the system of record. This +allows local writes and avoids conflicts. In order for a central system to keep track of the domain IDs, and to synchronize them across different servers, one of the systems needs to be able to explicitly assign them. - - Proposed Change =============== When creating a domain, the user can pass the optional parameter `explicit_domain_id` to be used when creating the domain. A domain -created this way will not use an autogenerated id, but will use the id +created this way will not use an auto-generated ID, but will use the id passed in instead. Identifiers passed in this way must conform to the existing ID -generation scheme: UUID4 without dashes. - +generation scheme: UUID4 without dashes. Note that this API will only be +accessible via system membership, restricting it to deployment administrators +and operators. Alternatives ------------ @@ -101,7 +99,6 @@ problem where users are stored in one Keystone server, but need access to a separate cloud. As such, K2K will suffer from all the same problems as any of Federated Identity Provider. - Security Impact --------------- @@ -122,7 +119,6 @@ string, and not explicitly setable, the will not be a potential for "User_ID squatting." where a user pre-allocates an entry to block another user. - Notifications Impact -------------------- @@ -155,10 +151,9 @@ Implementation Assignee(s) ----------- - Primary assignee: -Adam Young + * Adam Young Work Items ---------- @@ -167,7 +162,6 @@ Change to Keystone Server Change to Openstack SDK Change to OpenStack CLI - Dependencies ============