Browse Source

Clean up explicit domain IDs specification

Change-Id: I685e8aff8deda7a2bb6563989bf62252ecf05f25
changes/24/612524/1
Lance Bragstad 8 months ago
parent
commit
c54a16fd19
1 changed files with 16 additions and 22 deletions
  1. 16
    22
      specs/keystone/stein/explicit-domains-ids.rst

+ 16
- 22
specs/keystone/stein/explicit-domains-ids.rst View File

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

Loading…
Cancel
Save