openstack
/
keystone
Code Issues Proposed changes

Update doc id-manage.rst 

This patch removes about controller and replaces it with API. It
also add some links to the details mentioned in doc.

Change-Id: I558e6db1e0e920a5a22c1708e35553f1af678476
This commit is contained in:
Vishakha Agarwal 2020-04-27 18:04:22 +05:30
parent 07abf2fa4d
commit f8317375ab
2 changed files with 10 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
doc/source/admin/domain-specific-config.inc
View File

@ -19,6 +19,8 @@ database using API REST calls.
experimental in Kilo, and added to the Identity service in the
Liberty release.
.. _enable_drivers_for_domain:
Enable drivers for domain-specific configuration files
------------------------------------------------------

16
doc/source/contributor/id-manage.rst
View File

@ -14,18 +14,18 @@
License for the specific language governing permissions and limitations
under the License.
Identity entity ID management between controllers and drivers
=============================================================
Identity entity ID management for domain-specific backends
==========================================================
Keystone supports the option of having domain-specific backends for the
identity driver (i.e. for user and group storage), allowing, for example,
a different LDAP server for each domain. To ensure that Keystone can determine
to which backend it should route an API call, starting with Juno, the
identity manager will, provided that domain-specific backends are enabled,
build on-the-fly a persistent mapping table between Keystone Public IDs that
are presented to the controller and the domain that holds the entity, along
with whatever local ID is understood by the driver. This hides, for instance,
the LDAP specifics of whatever ID is being used.
identity manager will, provided that :ref:`domain-specific backends <enable_drivers_for_domain>`
are enabled, build on-the-fly a persistent mapping
table between Keystone Public IDs that are presented to the API and the domain
that holds the entity, along with whatever local ID is understood by the driver.
This hides, for instance, the LDAP specifics of whatever ID is being used.
To ensure backward compatibility, the default configuration of either a
single SQL or LDAP backend for Identity will not use the mapping table,
@ -33,4 +33,4 @@ meaning that public facing IDs will be the unchanged. If keeping these IDs
the same for the default LDAP backend is not required, then setting the
configuration variable ``backward_compatible_ids`` to ``False`` will enable
the mapping for the default LDAP driver, hence hiding the LDAP specifics of the
IDs being used.
IDs being used.