f10f95b455
Our tools noticed that keystone links to https://docs.openstack.org/keystone/latest/admin/identity-domain-specific-config.html which does not exist anymore. The page was removed but the link to it was not changed. Replace this and similar links with internal links that will work even if files are moved - and can be verified, thus sphinx will error in case of broken targets. These changes include a few other fixes for broken keystone links, e.g. to renamed anchors. For the include files in admin/configuration.rst and admin/federation/configure_federation.rst: Rename them to *inc. The files were published twice (as separate files and on this page) and thus referencing failed. Renaming avoids this. Also, put doctree outside of html tree so that it does not get published. Change-Id: I3d07637b0046cc88a66bcb51a0a4fe7c146c1549
1.3 KiB
1.3 KiB
Configuring Keystone
Identity sources
One of the most impactful decisions you'll have to make when configuring keystone is deciding how you want keystone to source your identity data. Keystone supports several different choices that will substantially impact how you'll configure, deploy, and interact with keystone.
You can also mix-and-match various sources of identity (see Domain-specific Configuration <domain_specific_configuration>
for an example). For example, you can store OpenStack service users and
their passwords in SQL, manage customers in LDAP, and authenticate
employees via SAML federation.