1a50986e7c
The current code has a number of problems and limitations in its support for having domain-specific backends (e.g. a different LDAP server per domain). Not least of the problems is that you cannot always infer the domain if an API call is just handed a user_id or group_id. These issues are so severe that this feature is currently marked as experimental. This patch fixes these issues by using a mapping layer to store the domain and local ID for the public facing user and group IDs. No API changes are required for this new support. An important consequence of this change is that non-UUID IDs for backends like LDAP do not escape from keystone. To ensure backward compatibility with existing single backend installations, the mapping is not used for the default driver. An exception to this is that if a cloud provider wants to enable mapping for the default LDAP driver then they can set a config option to achieve this. keystone-manage has been extended to provide options to purge the mapping table. Blueprint: multi-backend-uuids Change-Id: I60f8965bb74b248e6a6c8f141289affa431ee3cf |
||
|---|---|---|
| .. | ||
| default_catalog.templates | ||
| keystone-paste.ini | ||
| keystone.conf.sample | ||
| logging.conf.sample | ||
| policy.json | ||
| policy.v3cloudsample.json | ||