The main components of Identity user management are: User. Represents a human user. Has associated information such as user name, password, and email. This example creates a user named alice: $ openstack user create --password-prompt --email alice@example.com alice Project. A tenant, group, or organization. When you make requests to OpenStack services, you must specify a project. For example, if you query the Compute service for a list of running instances, you get a list of all running instances in the project that you specified in your query. This example creates a project named acme: $ openstack project create acme Domain. Defines administrative boundaries for the management of Identity entities. A domain may represent an individual, company, or operator-owned space. It is used for exposing administrative activities directly to the system users. A domain is a collection of projects and users. Users may be given a domain's administrator role. A domain administrator may create projects, users, and groups within a domain and assign roles to users and groups. This example creates a domain named emea: $ openstack domain create emea Role. Captures the operations that a user can perform in a given tenant. This example creates a role named compute-user: $ openstack role create compute-user Individual services, such as Compute and the Image service, assign meaning to roles. In the Identity Service, a role is simply a name. The Identity Service assigns a tenant and a role to a user. You might assign the compute-user role to the alice user in the acme tenant: $ openstack user list +--------+-------+ | ID | Name | +--------+-------+ | 892585 | alice | +--------+-------+ $ openstack role list +--------+---------------+ | ID | Name | +--------+---------------+ | 9a764e | compute-user | +--------+---------------+ $ openstack project list +--------+--------------------+ | ID | Name | +--------+--------------------+ | 6b8fd2 | acme | +--------+--------------------+ $ openstack role add --project 6b8fd2 --user 892585 9a764e A user can have different roles in different tenants. For example, Alice might also have the admin role in the Cyberdyne tenant. A user can also have multiple roles in the same tenant. The /etc/[SERVICE_CODENAME]/policy.json file controls the tasks that users can perform for a given service. For example, /etc/nova/policy.json specifies the access policy for the Compute service, /etc/glance/policy.json specifies the access policy for the Image service, and /etc/keystone/policy.json specifies the access policy for the Identity Service. The default policy.json files in the Compute, Identity, and Image service recognize only the admin role: all operations that do not require the admin role are accessible by any user that has any role in a tenant. If you wish to restrict users from performing operations in, say, the Compute service, you need to create a role in the Identity Service and then modify /etc/nova/policy.json so that this role is required for Compute operations. For example, this line in /etc/nova/policy.json specifies that there are no restrictions on which users can create volumes: if the user has any role in a tenant, they can create volumes in that tenant. "volume:create": "", To restrict creation of volumes to users who had the compute-user role in a particular tenant, you would add "role:compute-user", like so: "volume:create": "role:compute-user", To restrict all Compute service requests to require this role, the resulting file would look like: