Update Identity service intro and concepts
Updates Identity service information in the Get Started with OpenStack chapter and moves Identity concepts information to the Identity Management chapter. Change-Id: Icdffc456a258cc16a2ced8743897f8c647b997b9 Closes-Bug: #1239308
This commit is contained in:
parent
a5fb08c966
commit
107ddb1a65
@ -2,63 +2,122 @@
|
|||||||
Identity concepts
|
Identity concepts
|
||||||
=================
|
=================
|
||||||
|
|
||||||
User management
|
Authentication
|
||||||
~~~~~~~~~~~~~~~
|
The process of confirming the identity of a user.
|
||||||
|
OpenStack Identity confirms an incoming request
|
||||||
|
by validating a set of credentials supplied by the
|
||||||
|
user. These credentials are initially a user name and
|
||||||
|
password, or a user name and API key. When user
|
||||||
|
credentials are validated, OpenStack Identity issues an
|
||||||
|
authentication token which the user provides in subsequent
|
||||||
|
requests.
|
||||||
|
|
||||||
The main components of Identity user management are:
|
Credentials
|
||||||
|
Data that confirms the user's identity. For
|
||||||
|
example: user name and password, user name and API
|
||||||
|
key, or an authentication token provided by the
|
||||||
|
Identity service.
|
||||||
|
|
||||||
* User
|
Domain
|
||||||
Represents a human user. Has associated information such as
|
A domain is a collection of projects and users. It defines administrative
|
||||||
user name, password, and email. This example creates a user named
|
boundaries for the management of Identity entities. A domain may represent
|
||||||
``alice``:
|
an individual, company, or operator-owned space. It is used for exposing
|
||||||
|
administrative activities directly to the system users. Users may be given
|
||||||
.. code::
|
a domain's administrator role. A domain administrator may create
|
||||||
|
|
||||||
$ 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``:
|
|
||||||
|
|
||||||
.. code::
|
|
||||||
|
|
||||||
$ 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
|
projects, users, and groups within a domain and assign roles to users
|
||||||
and groups.
|
and groups.
|
||||||
|
|
||||||
This example creates a domain named ``emea``:
|
Endpoint
|
||||||
|
A network-accessible address where you access a service,
|
||||||
|
usually a URL address. If you are using an extension for
|
||||||
|
templates, an endpoint template can be created, which
|
||||||
|
represents the templates of all the consumable services
|
||||||
|
that are available across the regions.
|
||||||
|
|
||||||
.. code::
|
OpenStackClient
|
||||||
|
A command-line interface for several OpenStack services
|
||||||
|
including the Identity API. For example, users can run the
|
||||||
|
:command:`openstack service create` and
|
||||||
|
:command:`openstack endpoint create` commands
|
||||||
|
to register services in their OpenStack
|
||||||
|
installations.
|
||||||
|
|
||||||
$ openstack --os-identity-api-version=3 domain create emea
|
Project
|
||||||
|
A container used to group or isolate resources.
|
||||||
|
Projects also group or isolate identity objects.
|
||||||
|
Depending on the service operator, a project may map
|
||||||
|
to a customer, account, organization, or tenant.
|
||||||
|
|
||||||
* Role
|
Role
|
||||||
Captures the operations that a user can perform in a given
|
A personality with a defined set of user rights and
|
||||||
tenant.
|
privileges to perform a specific set of operations.
|
||||||
|
In the Identity service, a token that is issued
|
||||||
|
to a user includes the list of roles. Services that are
|
||||||
|
being called by that user determine how they interpret the
|
||||||
|
set of roles a user has and to which operations or
|
||||||
|
resources each role grants access.
|
||||||
|
|
||||||
This example creates a role named ``compute-user``:
|
Service
|
||||||
|
An OpenStack service, such as Compute (nova),
|
||||||
|
Object Storage (swift), or Image service (glance).
|
||||||
|
It provides one or more endpoints in which
|
||||||
|
users can access resources and perform operations.
|
||||||
|
|
||||||
.. code::
|
Token
|
||||||
|
An alpha-numeric string of text used to access
|
||||||
|
OpenStack APIs and resources. A token may be
|
||||||
|
revoked at any time and is valid for a
|
||||||
|
finite duration. While OpenStack Identity supports token-based
|
||||||
|
authentication in this release, the intention is
|
||||||
|
to support additional protocols in the future.
|
||||||
|
Its main purpose is to be an integration service,
|
||||||
|
and not aspire to be a full-fledged identity store
|
||||||
|
and management solution.
|
||||||
|
|
||||||
$ openstack role create compute-user
|
User
|
||||||
|
Digital representation of a person, system, or
|
||||||
|
service who uses OpenStack cloud services. The
|
||||||
|
Identity service validates that incoming requests
|
||||||
|
are made by the user who claims to be making the
|
||||||
|
call. Users have a login and may be assigned
|
||||||
|
tokens to access resources. Users can be directly
|
||||||
|
assigned to a particular project and behave as if
|
||||||
|
they are contained in that project.
|
||||||
|
|
||||||
.. note::
|
User management
|
||||||
|
~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
Individual services, such as Compute and the Image service,
|
Identity user management examples:
|
||||||
assign meaning to roles. In the Identity service, a role is
|
|
||||||
simply a name.
|
* Create a user named ``alice``:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ openstack user create --password-prompt --email alice@example.com alice
|
||||||
|
|
||||||
|
* Create a project named ``acme``:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ openstack project create acme
|
||||||
|
|
||||||
|
* Create a domain named ``emea``:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ openstack --os-identity-api-version=3 domain create emea
|
||||||
|
|
||||||
|
* Create a role named ``compute-user``:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ openstack role create compute-user
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
|
||||||
|
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
|
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``
|
assign the ``compute-user`` role to the ``alice`` user in the ``acme``
|
||||||
|
@ -2,85 +2,45 @@
|
|||||||
OpenStack Identity
|
OpenStack Identity
|
||||||
==================
|
==================
|
||||||
|
|
||||||
The OpenStack Identity service performs the following functions:
|
The OpenStack :term:`Identity service <Identity>` provides a single point of
|
||||||
|
integration for managing authentication, authorization, and service catalog
|
||||||
|
services. Other OpenStack services use the Identity service as a common
|
||||||
|
unified API. Additionally, services that provide information about users
|
||||||
|
but that are not included in OpenStack (such as LDAP services) can be
|
||||||
|
integrated into a pre-existing infrastructure.
|
||||||
|
|
||||||
- Tracking users and their permissions.
|
In order to benefit from the Identity service, other OpenStack services need to
|
||||||
|
collaborate with it. When an OpenStack service receives a request from a user,
|
||||||
|
it checks with the Identity service whether the user is authorized to make the
|
||||||
|
request.
|
||||||
|
|
||||||
- Providing a catalog of available services with their API endpoints.
|
The Identity service contains these components:
|
||||||
|
|
||||||
|
Server
|
||||||
|
A centralized server provides authentication and authorization
|
||||||
|
services using a RESTful interface.
|
||||||
|
|
||||||
|
Drivers
|
||||||
|
Drivers or a service back end are integrated to the centralized
|
||||||
|
server, and are used for accessing identity information in
|
||||||
|
repositories, external to OpenStack, and maybe already existing in
|
||||||
|
the infrastructure where OpenStack is deployed (for example, SQL
|
||||||
|
databases or LDAP servers).
|
||||||
|
|
||||||
|
Modules
|
||||||
|
Middleware modules run in the address space of the OpenStack
|
||||||
|
component that is using the Identity service. These modules
|
||||||
|
intercept service requests, extract user credentials, and send them
|
||||||
|
to the centralized server for authorization. The integration between
|
||||||
|
the middleware modules and OpenStack components uses the Python Web
|
||||||
|
Server Gateway Interface.
|
||||||
|
|
||||||
When installing OpenStack Identity service, you must register each
|
When installing OpenStack Identity service, you must register each
|
||||||
service in your OpenStack installation. Identity service can then track
|
service in your OpenStack installation. Identity service can then track
|
||||||
which OpenStack services are installed, and where they are located on
|
which OpenStack services are installed, and where they are located on
|
||||||
the network.
|
the network.
|
||||||
|
|
||||||
To understand OpenStack Identity, you must understand the following
|
|
||||||
concepts:
|
|
||||||
|
|
||||||
User
|
|
||||||
Digital representation of a person, system, or service who uses
|
|
||||||
OpenStack cloud services. The Identity service validates that
|
|
||||||
incoming requests are made by the user who claims to be making the
|
|
||||||
call. Users have a login and may be assigned tokens to access
|
|
||||||
resources. Users can be directly assigned to a particular tenant and
|
|
||||||
behave as if they are contained in that tenant.
|
|
||||||
|
|
||||||
Credentials
|
|
||||||
Data that confirms the user's identity. For example: user name and
|
|
||||||
password, user name and API key, or an authentication token provided
|
|
||||||
by the Identity service.
|
|
||||||
|
|
||||||
Authentication
|
|
||||||
The process of confirming the identity of a user. OpenStack Identity
|
|
||||||
confirms an incoming request by validating a set of credentials
|
|
||||||
supplied by the user.
|
|
||||||
|
|
||||||
These credentials are initially a user name and password, or a user
|
|
||||||
name and API key. When user credentials are validated, OpenStack
|
|
||||||
Identity issues an authentication token which the user provides in
|
|
||||||
subsequent requests.
|
|
||||||
|
|
||||||
Token
|
|
||||||
An alpha-numeric string of text used to access OpenStack APIs and
|
|
||||||
resources. A token may be revoked at any time and is valid for a
|
|
||||||
finite duration.
|
|
||||||
|
|
||||||
While OpenStack Identity supports token-based authentication in this
|
|
||||||
release, the intention is to support additional protocols in the
|
|
||||||
future. Its main purpose is to be an integration service, and not
|
|
||||||
aspire to be a full-fledged identity store and management solution.
|
|
||||||
|
|
||||||
Tenant
|
|
||||||
A container used to group or isolate resources. Tenants also group
|
|
||||||
or isolate identity objects. Depending on the service operator, a
|
|
||||||
tenant may map to a customer, account, organization, or project.
|
|
||||||
|
|
||||||
Service
|
|
||||||
An OpenStack service, such as Compute (nova), Object Storage
|
|
||||||
(swift), or Image service (glance). It provides one or more
|
|
||||||
endpoints in which users can access resources and perform
|
|
||||||
operations.
|
|
||||||
|
|
||||||
Endpoint
|
|
||||||
A network-accessible address where you access a service, usually a
|
|
||||||
URL address. If you are using an extension for templates, an
|
|
||||||
endpoint template can be created, which represents the templates of
|
|
||||||
all the consumable services that are available across the regions.
|
|
||||||
|
|
||||||
Role
|
|
||||||
A personality with a defined set of user rights and privileges to
|
|
||||||
perform a specific set of operations.
|
|
||||||
|
|
||||||
In the Identity service, a token that is issued to a user includes
|
|
||||||
the list of roles. Services that are being called by that user
|
|
||||||
determine how they interpret the set of roles a user has and to
|
|
||||||
which operations or resources each role grants access.
|
|
||||||
|
|
||||||
Keystone Client
|
|
||||||
A command line interface for the OpenStack Identity API. For
|
|
||||||
example, users can run the ``keystone service-create`` and
|
|
||||||
``keystone endpoint-create`` commands to register services in their
|
|
||||||
OpenStack installations.
|
|
||||||
|
|
||||||
The following diagram shows the OpenStack Identity process flow:
|
The following diagram shows the OpenStack Identity process flow:
|
||||||
|
|
||||||
.. image:: figures/SCH_5002_V00_NUAC-Keystone.png
|
.. image:: figures/SCH_5002_V00_NUAC-Keystone.png
|
||||||
|
:alt: OpenStack Identity process flow
|
||||||
|
Loading…
Reference in New Issue
Block a user