This chapter details the OpenStack Identity service configuration options. For installation prerequisites and step-by-step walkthroughs, see the OpenStack Installation Guide for your distribution (docs.openstack.org) and Cloud Administrator Guide.

Identity supports a caching layer that is above the configurable subsystems, such as token or assignment. The majority of the caching configuration options are set in the [cache] section. However, each section that has the capability to be cached usually has a caching option that will toggle caching for that specific section. By default, caching is globally disabled. Options are as follows: Current functional backends are: dogpile.cache.memcached - Memcached backend using the standard python-memcached library dogpile.cache.pylibmc - Memcached backend using the pylibmc library dogpile.cache.bmemcached - Memcached using python-binary-memcached library. dogpile.cache.redis - Redis backend dogpile.cache.dbm - Local DBM file backend dogpile.cache.memory - In-memory cache, not suitable for use outside of testing as it does not cleanup it's internal cache on cache expiration and does not share cache between processes. This means that caching and cache invalidation will not be consistent or reliable. dogpile.cache.mongo - MongoDB as caching backend.

The Identity service is configured in the /etc/keystone/keystone.conf file. The following tables provide a comprehensive list of the Identity service options.

The Identity service supports domain-specific Identity drivers which allow a domain to have its own LDAP or SQL back end. By default, domain-specific drivers are disabled. Domain-specific Identity configuration options can be stored in domain-specific configuration files, or in the Identity SQL database using API REST calls. Storing and managing configuration options in a SQL database is experimental in Kilo.

To enable domain-specific drivers, set these options in the /etc/keystone/keystone.conf file: [identity] domain_specific_drivers_enabled = True domain_config_dir = /etc/keystone/domains When you enable domain-specific drivers, Identity looks in the domain_config_dir directory for configuration files that are named as keystone.DOMAIN_NAME.conf. Any domain without a domain-specific configuration file uses options in the primary configuration file.

Any options that you define in the domain-specific configuration file override options in the /etc/keystone/keystone.conf configuration file. Domains configured for the service user or project use the Identity API v3 to retrieve the service token. To configure the domain for the service user, set the following options in the [DEFAULT] section of the /etc/keystone/domains/keystone.DOMAIN_NAME.conf file: admin_user_domain_id = USER_DOMAIN_ID admin_user_domain_name = USER_DOMAIN_NAME Replace USER_DOMAIN_ID with the Identity service account user domain ID, and USER_DOMAIN_NAME with the Identity service account user domain name. To configure the domain for the project, set the following options in the [DEFAULT] section of the /etc/keystone/domains/keystone.DOMAIN_NAME.conf file: admin_project_domain_id = PROJECT_DOMAIN_ID admin_project_domain_name = PROJECT_DOMAIN_NAME Replace PROJECT_DOMAIN_ID with the Identity service account project domain ID, and PROJECT_DOMAIN_NAME with the Identity service account project domain name.

To enable domain-specific drivers, set these options in the /etc/keystone/keystone.conf file: [identity] domain_specific_drivers_enabled = True domain_configurations_from_database = True Any domain-specific configuration options specified through the Identity v3 API will override domain-specific configuration files in the /etc/keystone/domains directory.

You can use the keystone-manage command to migrate configuration options in domain-specific configuration files to the SQL database: $ keystone-manage domain_config_upload --all To upload options from a specific domain-configuration file, specify the domain name: $ keystone-manage domain_config_upload --domain-name DOMAIN_NAME