Identity Management

User CRUD Keystone provides a user CRUD filter that can be added to the public_api pipeline. This user crud filter allows 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 will be deleted (if the backend used is kvs or sql)

Logging Logging is configured 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. If you wish to route all your 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. In addition to this documentation page, you can check 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, auth_token middleware can be alternatively configured in [keystone_authtoken] section in the main config file, such as nova.conf. For example in Nova, all middleware parameters can be removed from api-paste.ini like these: [filter:authtoken] paste.filter_factory = keystoneclient.middleware.auth_token:filter_factory and set in nova.conf like these: [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 Note that middleware parameters in paste config take priority, they must be removed to use values in [keystone_authtoken] section.

Monitoring 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

Running Running Identity is simply starting the services by using the command: $ keystone-all Invoking this command starts up two wsgi.Server instances, configured by the keystone.conf file as described above. One of these wsgi 'servers' is admin (the administration API) and the other is main (the primary/public API interface). Both of these run in a single process.

Example usage 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

Auth-Token Middleware with Username and Password It is also possible to configure Keystone's 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 will by 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.