06062151de
Since the keystone-manage bootstrap command has been implemented we can refactor our installation process to use that, instead of creating the Identity service and endpoints manually with the ADMIN_TOKEN. This also includes moving a bunch of the information in keystone-services.rst to the get-started-identity.rst guide, since creating the keystone service and endpoints manually is no longer required (bootstrap does this for us now). The remaining information in keystone-services.rst for exporting environment variables to use the ``openstack`` client were moved to the keystone-install.rst document since that's essentially the last step of keystone's installation and configuration. Change-Id: I6be3f286daf968dddf808f0204f2b317a5f09a59
55 lines
2.8 KiB
ReStructuredText
55 lines
2.8 KiB
ReStructuredText
=========================
|
|
Identity service overview
|
|
=========================
|
|
|
|
The OpenStack :term:`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, and 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.
|