Clean up explicit domain IDs specification
Change-Id: I685e8aff8deda7a2bb6563989bf62252ecf05f25
This commit is contained in:
Lance Bragstad
parent
8b3cda6078
commit
c54a16fd19
|
|
@ -10,7 +10,6 @@ Explicit Domain IDs
|
|||
|
||||
`Explicit Domain IDs <https://bugs.launchpad.net/keystone/+bug/1794527>`_
|
||||
|
||||
|
||||
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 <ayoung>
|
||||
|
||||
* Adam Young <ayoung>
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
|
@ -167,7 +162,6 @@ Change to Keystone Server
|
|||
Change to Openstack SDK
|
||||
Change to OpenStack CLI
|
||||
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue