keystone/keystone/tests/backend_multi_ldap_sql.conf
Henry Nash 1ed2046eaa Implement domain specific Identity backends
A common scenario in shared clouds will be that a cloud provider will
want to be able to offer larger customers the ability to interface to
their chosen identity provider. In the base case, this might well be
their own corporate LDAP/AD directory.  A cloud provider might also
want smaller customers to have their identity managed solely
within the OpenStack cloud, perhaps in a shared SQL database.

This patch allows domain specific backends for identity objects
(namely user and groups), which are specified by creation of a domain
configuration file for each domain that requires its own backend.

A side benefit of this change is that it clearly separates the
backends into those that are domain-aware and those that are not,
allowing, for example, the removal of domain validation from the
LDAP identity backend.

Implements bp multiple-ldap-servers

DocImpact

Change-Id: I489e8e50035f88eca4235908ae8b1a532645daab
2013-08-15 23:41:15 +01:00

36 lines
934 B
Plaintext

[sql]
connection = sqlite://
#For a file based sqlite use
#connection = sqlite:////tmp/keystone.db
#To Test MySQL:
#connection = mysql://keystone:keystone@localhost/keystone?charset=utf8
#To Test PostgreSQL:
#connection = postgresql://keystone:keystone@localhost/keystone?client_encoding=utf8
idle_timeout = 200
[identity]
# common identity backend is SQL, domain specific configs will
# set their backends to ldap
driver = keystone.identity.backends.sql.Identity
# The test setup will set this to True, to allow easier creation
# of initial domain data
# domain_specific_drivers_enabled = True
[assignment]
driver = keystone.assignment.backends.sql.Assignment
[token]
driver = keystone.token.backends.sql.Token
[ec2]
driver = keystone.contrib.ec2.backends.sql.Ec2
[catalog]
driver = keystone.catalog.backends.sql.Catalog
[policy]
driver = keystone.policy.backends.sql.Policy
[trust]
driver = keystone.trust.backends.sql.Trust