The default identity management system for OpenStack is the OpenStack Identity Service, code-named Keystone. Once Identity is installed, it is configured via a primary configuration file (etc/keystone.conf), possibly a separate logging configuration file, and initializing data into keystone using the command line client.

Keystone 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 app in the public_api WSGI pipeline in keystone.conf e.g.: [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 users current tokens are deleted (if the back end is kvs or sql).

You configure logging externally to the rest of Identity. 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 directory etc/logging.conf.sample. Like other OpenStack projects, Identity uses the python logging module, which includes extensive configuration options for choosing the output levels and formats. Review the etc/keystone.conf sample configuration files distributed with keystone for example configuration files for each server application. For services which have separate paste-deploy ini file, you can configure auth_token middleware in [keystone_authtoken] section in the main config 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 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 Middleware parameters in paste config take priority. You must remove them to use values in [keystone_authtoken] section.

Keystone 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 SERVICE_ENDPOINT=http://127.0.0.1:5000/v2.0/ export SERVICE_TOKEN=secrete_token keystone user-list keystone tenant-create --name=demo # Using token auth flags keystone --token=secrete --endpoint=http://127.0.0.1:5000/v2.0/ user-list keystone --token=secrete --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

It is also possible to configure the Identity Service Auth-Token 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. Here is an example paste config filter that makes use of the admin_user and admin_password parameters: [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 It should be noted that when using this option an admin tenant/role relationship is required. The admin user is granted access to the Admin role on the admin tenant.