The OpenStack Identity Service, code-named keystone, is the default identity management system for OpenStack. After you install the Identity Service, you configure it through the etc/keystone.conf configuration file and, possibly, a separate logging configuration file. You initialize data into the Identity Service by using the keystone command-line client.

The Identity Service provides a user CRUD filter that can be added to the public_api pipeline. This user CRUD filter enables users to use a HTTP PATCH to change their own password. To enable this extension you should define a user_crud_extension filter, insert it after the *_body middleware and before the public_service application in the public_api WSGI pipeline in keystone.conf. For example: [filter:user_crud_extension] paste.filter_factory = keystone.contrib.user_crud:CrudExtension.factory [pipeline:public_api] pipeline = stats_monitoring url_normalize token_auth admin_token_auth xml_body json_body debug ec2_extension user_crud_extension public_service Each user can then change their own password with a HTTP PATCH: $ curl -X PATCH http://localhost:5000/v2.0/OS-KSCRUD/users/<userid> -H "Content-type: application/json" \ -H "X_Auth_Token: <authtokenid>" -d '{"user": {"password": "ABCD", "original_password": "DCBA"}}' In addition to changing their password, all of the user's current tokens are deleted (if the back-end is KVS or sql). Only use a KVS backend for tokens when testing.

You configure logging externally to the rest of the Identity Service. The file specifying the logging configuration is in the [DEFAULT] section of the keystone.conf file under log_config. To route logging through syslog, set use_syslog=true option in the [DEFAULT] section. A sample logging file is available with the project in the etc/logging.conf.sample directory. Like other OpenStack projects, the Identity Service uses the Python logging module, which includes extensive configuration options that let you define the output levels and formats. Review the etc/keystone.conf sample configuration files that are distributed with the Identity Service. For example, each server application has its own configuration file. For services that have separate paste-deploy .ini files, you can configure auth_token middleware in the [keystone_authtoken] section in the main configuration file, such as nova.conf. For example in Compute, you can remove the middleware parameters from api-paste.ini, as follows: [filter:authtoken] paste.filter_factory = keystoneclient.middleware.auth_token:filter_factory Set these values in the nova.conf file: [DEFAULT] ... auth_strategy=keystone [keystone_authtoken] auth_host = 127.0.0.1 auth_port = 35357 auth_protocol = http auth_uri = http://127.0.0.1:5000/ admin_user = admin admin_password = SuperSekretPassword admin_tenant_name = service Middleware parameters in paste config take priority. You must remove them to use values in the [keystone_authtoken] section.

The Identity Service provides some basic request/response monitoring statistics out of the box. Enable data collection by defining a stats_monitoring filter and including it at the beginning of any desired WSGI pipelines: [filter:stats_monitoring] paste.filter_factory = keystone.contrib.stats:StatsMiddleware.factory [pipeline:public_api] pipeline = stats_monitoring [...] public_service Enable the reporting of collected data by defining a stats_reporting filter and including it near the end of your admin_api WSGI pipeline (After *_body middleware and before *_extension filters is recommended): [filter:stats_reporting] paste.filter_factory = keystone.contrib.stats:StatsExtension.factory [pipeline:admin_api] pipeline = [...] json_body stats_reporting ec2_extension [...] admin_service Query the admin API for statistics using: $ curl -H 'X-Auth-Token: ADMIN' http://localhost:35357/v2.0/OS-STATS/stats Reset collected data using: $ curl -H 'X-Auth-Token: ADMIN' -X DELETE \ http://localhost:35357/v2.0/OS-STATS/stats

To start the services for the Identity Service, run the following command: $ keystone-all This command starts two wsgi.Server instances configured by the keystone.conf file as described previously. One of these wsgi servers is admin (the administration API) and the other is main (the primary/public API interface). Both run in a single process.

The keystone client is set up to expect commands in the general form of keystone command argument, followed by flag-like keyword arguments to provide additional (often optional) information. For example, the command user-list and tenant-create can be invoked as follows: # Using token auth env variables export OS_SERVICE_ENDPOINT=http://127.0.0.1:5000/v2.0/ export OS_SERVICE_TOKEN=secrete_token keystone user-list keystone tenant-create --name=demo # Using token auth flags keystone --os-token=secrete --os-endpoint=http://127.0.0.1:5000/v2.0/ user-list keystone --os-token=secrete --os-endpoint=http://127.0.0.1:5000/v2.0/ tenant-create --name=demo # Using user + password + tenant_name env variables export OS_USERNAME=admin export OS_PASSWORD=secrete export OS_TENANT_NAME=admin keystone user-list keystone tenant-create --name=demo # Using user + password + tenant_name flags keystone --username=admin --password=secrete --tenant_name=admin user-list keystone --username=admin --password=secrete --tenant_name=admin tenant-create --name=demo

You can also configure the Identity Service authentication middleware using the admin_user and admin_password options. When using the admin_user and admin_password options the admin_token parameter is optional. If admin_token is specified, it is used only if the specified token is still valid. For services that have a separate paste-deploy .ini file, you can configure the authentication middleware in the [keystone_authtoken] section of the main configuration file, such as nova.conf. In Compute, for example, you can remove the middleware parameters from api-paste.ini, as follows: [filter:authtoken] paste.filter_factory = keystoneclient.middleware.auth_token:filter_factory And set the following values in nova.conf as follows: [DEFAULT] ... auth_strategy=keystone [keystone_authtoken] auth_host = 127.0.0.1 auth_port = 35357 auth_protocol = http auth_uri = http://127.0.0.1:5000/ admin_user = admin admin_password = SuperSekretPassword admin_tenant_name = service The middleware parameters in the paste config take priority. You must remove them to use the values in the [keystone_authtoken] section. This sample paste config filter makes use of the admin_user and admin_password options: [filter:authtoken] paste.filter_factory = keystoneclient.middleware.auth_token:filter_factory service_port = 5000 service_host = 127.0.0.1 auth_port = 35357 auth_host = 127.0.0.1 auth_token = 012345SECRET99TOKEN012345 admin_user = admin admin_password = keystone123 Using this option requires an admin tenant/role relationship. The admin user is granted access to the admin role on the admin tenant.