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

Identity 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 current tokens for the user are deleted (if the back end is KVS or SQL). Only use a KVS back end for tokens when testing.

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 etc/logging.conf.sample directory. Like other OpenStack projects, Identity 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.

Identity provides some basic request and 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 Identity, 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 Identity 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.

Like most OpenStack projects, Identity supports the protection of its APIs by defining policy rules based on an RBAC approach. Identity stores a reference to a policy JSON file in the main Identity configuration file, keystone.conf. Typically this file is named policy.json, and it contains the rules for which roles have access to certain actions in defined services. Each Identity API v3 call has a line in the policy file that dictates which level of governance of access applies. API_NAME: RULE_STATEMENT or MATCH_STATEMENT Where: RULE_STATEMENT can contain RULE_STATEMENT or MATCH_STATEMENT. MATCH_STATEMENT is a set of identifiers that must match between the token provided by the caller of the API and the parameters or target entities of the API call in question. For example: "identity:create_user": [["role:admin", "domain_id:%(user.domain_id)s"]] Indicates that to create a user, you must have the admin role in your token and the domain_id in your token (which implies this must be a domain-scoped token) must match the domain_id in the user object that you are trying to create. In other words, you must have the admin role on the domain in which you are creating the user, and the token that you use must be scoped to that domain. Each component of a match statement uses this format: ATTRIB_FROM_TOKEN:CONSTANT or ATTRIB_RELATED_TO_API_CALL The Identity service expects these attributes: Attributes from token: user_id, the domain_id or project_id depending on the scope, and the list of roles you have within that scope. Attributes related to API call: Any parameters passed into the API call are available, along with any filters specified in the query string. You reference attributes of objects passed with an object.attribute syntax (such as, user.domain_id). The target objects of an API are also available using a target.object.attribute syntax. For instance: "identity:delete_user": [["role:admin", "domain_id:%(target.user.domain_id)s"]] would ensure that Identity only deletes the user object in the same domain as the provided token. Every target object has an `id` and a `name` available as `target.OBJECT.id` and `target.OBJECT.name`. Identity retrieves other attributes from the database, and the attributes vary between object types. The Identity service filters out some database fields, such as user passwords. List of object attributes: role: target.role.id target.role.name user: target.user.default_project_id target.user.description target.user.domain_id target.user.enabled target.user.id target.user.name group: target.group.description target.group.domain_id target.group.id target.group.name domain: target.domain.enabled target.domain.id target.domain.name project: target.project.description target.project.domain_id target.project.enabled target.project.id target.project.name The default policy.json file supplied provides a somewhat basic example of API protection, and does not assume any particular use of domains. Refer to policy.v3cloudsample.json as an example of multi-domain configuration installations where a cloud provider wants to delegate administration of the contents of a domain to a particular admin domain. This example policy file also shows the use of an admin_domain to allow a cloud provider to enable cloud administrators to have wider access across the APIs. A clean installation could start with the standard policy file, to allow creation of the admin_domain with the first users within it. You could then obtain the domain_id of the admin domain, paste the ID into a modified version of policy.v3cloudsample.json, and then enable it as the main policy file.