04515333f4
This change breaks the get-started-identity, keystone-users, and keystone-openrc pages into multiple copies for each distribution release in the keystone install guides. Before this change, sphinx would not render the links correctly and these pages would be skipped in both the RDO and Ubuntu guides. To avoid unneccessary duplication of the same text, the files were moved into common/ and are simply included into the newly created files for each release. Change-Id: I7b478504f1e68034ea993c0214705045da86bb6e Closes-Bug: #1712335
53 lines
2.7 KiB
HTML
53 lines
2.7 KiB
HTML
Identity service overview
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The OpenStack Identity service provides a single point of integration for
|
|
managing authentication, authorization, and a catalog of services.
|
|
|
|
The Identity service is typically the first service a user interacts with. Once
|
|
authenticated, an end user can use their identity to access other OpenStack
|
|
services. Likewise, other OpenStack services leverage the Identity service to
|
|
ensure users are who they say they are and discover where other services are
|
|
within the deployment. The Identity service can also integrate with some
|
|
external user management systems (such as LDAP).
|
|
|
|
Users and services can locate other services by using the service catalog,
|
|
which is managed by the Identity service. As the name implies, a service
|
|
catalog is a collection of available services in an OpenStack deployment. Each
|
|
service can have one or many endpoints and each endpoint can be one of three
|
|
types: admin, internal, or public. In a production environment, different
|
|
endpoint types might reside on separate networks exposed to different types of
|
|
users for security reasons. For instance, the public API network might be
|
|
visible from the Internet so customers can manage their clouds. The admin API
|
|
network might be restricted to operators within the organization that manages
|
|
cloud infrastructure. The internal API network might be restricted to the hosts
|
|
that contain OpenStack services. Also, OpenStack supports multiple regions for
|
|
scalability. For simplicity, this guide uses the management network for all
|
|
endpoint types and the default ``RegionOne`` region. Together, regions,
|
|
services, and endpoints created within the Identity service comprise the
|
|
service catalog for a deployment. Each OpenStack service in your deployment
|
|
needs a service entry with corresponding endpoints stored in the Identity
|
|
service. This can all be done after the Identity service has been installed and
|
|
configured.
|
|
|
|
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. They are used for accessing identity information in
|
|
repositories external to OpenStack, and may already exist 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.
|