summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLance Bragstad <lbragstad@gmail.com>2018-10-22 21:47:28 +0000
committerLance Bragstad <lbragstad@gmail.com>2018-10-22 21:47:28 +0000
commitc54a16fd19fd984f8cfe6eb3367c5aa0d872e314 (patch)
tree5787a9df55fa494f9bc600bc8f50f1a6e8c5ec26
parent8b3cda60786c7f62ab809811d85b747851114ffe (diff)
Clean up explicit domain IDs specification
Notes
Notes (review): Code-Review+2: Morgan Fainberg <morgan.fainberg@gmail.com> Workflow+1: Morgan Fainberg <morgan.fainberg@gmail.com> Verified+2: Zuul Submitted-by: Zuul Submitted-at: Mon, 22 Oct 2018 22:50:39 +0000 Reviewed-on: https://review.openstack.org/612524 Project: openstack/keystone-specs Branch: refs/heads/master
-rw-r--r--specs/keystone/stein/explicit-domains-ids.rst38
1 files changed, 16 insertions, 22 deletions
diff --git a/specs/keystone/stein/explicit-domains-ids.rst b/specs/keystone/stein/explicit-domains-ids.rst
index 6f9ff21..3eb88cc 100644
--- a/specs/keystone/stein/explicit-domains-ids.rst
+++ b/specs/keystone/stein/explicit-domains-ids.rst
@@ -10,7 +10,6 @@ Explicit Domain IDs
10 10
11`Explicit Domain IDs <https://bugs.launchpad.net/keystone/+bug/1794527>`_ 11`Explicit Domain IDs <https://bugs.launchpad.net/keystone/+bug/1794527>`_
12 12
13
14Problem Description 13Problem Description
15=================== 14===================
16 15
@@ -29,14 +28,14 @@ multiple deployments then has to correlate the user IDs across
29different Keystone servers. 28different Keystone servers.
30 29
31To avoid this, operators want to keep the LDAP users in a domain with 30To avoid this, operators want to keep the LDAP users in a domain with
32a consistant ID across deployments. The only domain with a 31a consistent ID across deployments. The only domain with a
33predictable ID, however, is `default.` THe default domain is used 32predictable ID, however, is `default.` Tee default domain is used
34during the initial install, and thus has service users. Thus, it is 33during the initial install, and thus has service users. Thus, it is
35inpractical to put the LDAP users in the default domain. If a site 34impractical to put the LDAP users in the default domain. If a site
36wished to have two LDAP servers in domain specific backends, only one 35wished to have two LDAP servers in domain specific backends, only one
37could be put in default. 36could be put in default.
38 37
39Today, if a depoloyer desires to keep two Keystone servers in sync 38Today, if a deployer desires to keep two Keystone servers in sync
40while avoiding Database replication, they must hack the database to 39while avoiding Database replication, they must hack the database to
41update the Domain ID so that entries match. Domain ID is then used for 40update the Domain ID so that entries match. Domain ID is then used for
42LDAP mapped IDs, and if they don't match, the user IDs are 41LDAP 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,
44so that the two servers can match User IDs. 43so that the two servers can match User IDs.
45 44
46An additional effort is underway to make the Federated Identity 45An additional effort is underway to make the Federated Identity
47sources use the same mechanism as LDAP. This effort is hampered 46sources use the same mechanism as LDAP. This effort is hampered
48by the same domain_id restrictions as LDAP. 47by the same domain_id restrictions as LDAP.
49 48
50Making the identifiers consistant across multiple deployments will aid 49Making the identifiers consistent across multiple deployments will aid
51in several use cases: 50in several use cases:
52 51
53It will make it easier to synchronize role assignments across two 52It 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
55second. 54second.
56 55
57Applications will now be able to predict what user-id a user would 56Applications will now be able to predict what user-id a user would
58have in a cluster, even before that user visits the cluster. This 57have in a cluster, even before that user visits the cluster. This
59allows the system to pre-create user records, and have them link to 58allows the system to pre-create user records, and have them link to
60the identity source when the user does finally authenticate to the 59the identity source when the user does finally authenticate to the
61Keystone server. 60Keystone server.
62 61
63One structure that can be used for multiple depoloyments is for each 62One structure that can be used for multiple deployments is for each
64Keystone server to represent a different region, and for each region 63Keystone server to represent a different region, and for each region
65to have a set of domains for which it is the system of record. This 64to have a set of domains for which it is the system of record. This
66allows local writes and avoids conflicts. In order for a central 65allows local writes and avoids conflicts. In order for a central
67system to keep track of the domain IDs, and to synchronize them across 66system to keep track of the domain IDs, and to synchronize them across
68different servers, one of the systems needs to be able to explicitly 67different servers, one of the systems needs to be able to explicitly
69assign them. 68assign them.
70 69
71
72
73Proposed Change 70Proposed Change
74=============== 71===============
75 72
76When creating a domain, the user can pass the optional parameter 73When creating a domain, the user can pass the optional parameter
77`explicit_domain_id` to be used when creating the domain. A domain 74`explicit_domain_id` to be used when creating the domain. A domain
78created this way will not use an autogenerated id, but will use the id 75created this way will not use an auto-generated ID, but will use the id
79passed in instead. 76passed in instead.
80 77
81Identifiers passed in this way must conform to the existing ID 78Identifiers passed in this way must conform to the existing ID
82generation scheme: UUID4 without dashes. 79generation scheme: UUID4 without dashes. Note that this API will only be
83 80accessible via system membership, restricting it to deployment administrators
81and operators.
84 82
85Alternatives 83Alternatives
86------------ 84------------
@@ -101,7 +99,6 @@ problem where users are stored in one Keystone server, but need access
101to a separate cloud. As such, K2K will suffer from all the same 99to a separate cloud. As such, K2K will suffer from all the same
102problems as any of Federated Identity Provider. 100problems as any of Federated Identity Provider.
103 101
104
105Security Impact 102Security Impact
106--------------- 103---------------
107 104
@@ -122,7 +119,6 @@ string, and not explicitly setable, the will not be a potential for
122"User_ID squatting." where a user pre-allocates an entry to block 119"User_ID squatting." where a user pre-allocates an entry to block
123another user. 120another user.
124 121
125
126Notifications Impact 122Notifications Impact
127-------------------- 123--------------------
128 124
@@ -155,10 +151,9 @@ Implementation
155Assignee(s) 151Assignee(s)
156----------- 152-----------
157 153
158
159Primary assignee: 154Primary assignee:
160Adam Young <ayoung>
161 155
156 * Adam Young <ayoung>
162 157
163Work Items 158Work Items
164---------- 159----------
@@ -167,7 +162,6 @@ Change to Keystone Server
167Change to Openstack SDK 162Change to Openstack SDK
168Change to OpenStack CLI 163Change to OpenStack CLI
169 164
170
171Dependencies 165Dependencies
172============ 166============
173 167