Merge "Update architecture documentation"

changes/30/80630/67
Jenkins 8 years ago committed by Gerrit Code Review
commit 24f101737c
  1. 86
      doc/source/architecture.rst

@ -27,7 +27,7 @@ The Services
Keystone is organized as a group of internal services exposed on one or many
endpoints. Many of these services are used in a combined fashion by the
frontend, for example an authenticate call will validate user/tenant
frontend, for example an authenticate call will validate user/project
credentials with the Identity service and, upon success, create and return a
token with the Token service.
@ -36,7 +36,7 @@ Identity
--------
The Identity service provides auth credential validation and data about Users,
Tenants and Roles, as well as any associated metadata.
Groups, Projects, Domains and Roles, as well as any associated metadata.
In the basic case all this data is managed by the service, allowing the service
to manage all the CRUD associated with the data.
@ -50,7 +50,7 @@ Token
-----
The Token service validates and manages Tokens used for authenticating requests
once a user/tenant's credentials have already been verified.
once a user's credentials have already been verified.
Catalog
@ -73,10 +73,13 @@ Application Construction
Keystone is an HTTP front-end to several services. Like other OpenStack
applications, this is done using python WSGI interfaces and applications are
configured together using Paste_. The application's HTTP endpoints are made up
of pipelines of WSGI middleware, such as::
of pipelines of WSGI middleware, such as:
[pipeline:public_api]
pipeline = token_auth admin_token_auth json_body debug ec2_extension public_service
.. code-block:: ini
[pipeline:api_v3]
pipeline = sizelimit url_normalize build_auth_context token_auth admin_token_auth
xml_body_v3 json_body ec2_extension_v3 s3_extension service_v3
These in turn use a subclass of :mod:`keystone.common.wsgi.ComposingRouter` to
link URLs to Controllers (a subclass of
@ -85,27 +88,35 @@ Managers are loaded (for example, see :mod:`keystone.catalog.core.Manager`),
which are thin wrapper classes which load the appropriate service driver based
on the Keystone configuration.
* Identity
* Assignment
* :mod:`keystone.assignment.controllers.DomainV3`
* :mod:`keystone.assignment.controllers.ProjectV3`
* :mod:`keystone.assignment.controllers.RoleV3`
* Authentication
* :mod:`keystone.identity.core.TenantController`
* :mod:`keystone.identity.core.UserController`
* :mod:`keystone.identity.core.RoleController`
* :mod:`keystone.auth.controllers.Auth`
* Catalog
* :mod:`keystone.catalog.core.ServiceController`
* :mod:`keystone.service.VersionController`
* :mod:`keystone.catalog.controllers.EndpointV3`
* :mod:`keystone.catalog.controllers.RegionV3`
* :mod:`keystone.catalog.controllers.ServiceV3`
* Token
* Identity
* :mod:`keystone.service.TokenController`
* :mod:`keystone.identity.controllers.GroupV3`
* :mod:`keystone.identity.controllers.UserV3`
* Misc
* Policy
* :mod:`keystone.service.ExtensionsController`
* :mod:`keystone.policy.controllers.PolicyV3`
* Token
* :mod:`keystone.token.controllers.Auth`
At this time, the policy service and associated manager is not exposed as a URL
frontend, and has no associated Controller class.
.. _Paste: http://pythonpaste.org/
@ -123,31 +134,25 @@ A general class under each backend named ``Driver`` exists to provide an
abstract base class for any implementations, identifying the expected service
implementations. The drivers for the services are:
* :mod:`keystone.assignment.core.Driver`
* :mod:`keystone.catalog.core.Driver`
* :mod:`keystone.identity.core.Driver`
* :mod:`keystone.policy.core.Driver`
* :mod:`keystone.token.core.Driver`
If you implement a backend driver for one of the Keystone services, you're
expected to subclass from these classes. The default response for the defined
APIs in these Drivers is to raise a :mod:`keystone.service.TokenController`.
expected to subclass from these classes.
SQL Backend
-----------
A SQL based backend using SQLAlchemy to store data persistently. The
keystone-manage command introspects the backends to identify SQL based backends
``keystone-manage`` command introspects the backends to identify SQL based backends
when running "db_sync" to establish or upgrade schema. If the backend driver
has a method db_sync(), it will be invoked to sync and/or migrate schema.
PAM Backend
-----------
Extra simple backend that uses the current system's PAM service to authenticate,
providing a one-to-one relationship between Users and Tenants with the `root`
User also having the 'admin' role.
Templated Backend
-----------------
@ -168,8 +173,8 @@ interpolation)::
LDAP Backend
------------
The LDAP backend stored Users and Tenants in separate Subtrees. Roles are recorded
as entries under the Tenants.
The LDAP backend stores Users and Projects in separate Subtrees. Roles are recorded
as entries under the Projects.
----------
@ -182,17 +187,18 @@ more data than they know what to do with and pass them on to a backend.
There are a few main data types:
* **User**: has account credentials, is associated with one or more tenants
* **Tenant**: unit of ownership in OpenStack, contains one or more users
* **Role**: a first-class piece of metadata associated with many user-tenant pairs.
* **Token**: identifying credential associated with a user or user and tenant
* **Extras**: bucket of key-value metadata associated with a user-tenant pair.
* **User**: has account credentials, is associated with one or more projects or domains
* **Group**: a collection of users, is associated with one or more projects or domains
* **Project**: unit of ownership in OpenStack, contains one or more users
* **Domain**: unit of ownership in OpenStack, contains users, groups and projects
* **Role**: a first-class piece of metadata associated with many user-project pairs.
* **Token**: identifying credential associated with a user or user and project
* **Extras**: bucket of key-value metadata associated with a user-project pair.
* **Rule**: describes a set of requirements for performing an action.
While the general data model allows a many-to-many relationship between Users
and Tenants and a many-to-one relationship between Extras and User-Tenant pairs,
the actual backend implementations take varying levels of advantage of that
functionality.
and Groups to Projects and Domains; the actual backend implementations take
varying levels of advantage of that functionality.
----------------
@ -200,7 +206,7 @@ Approach to CRUD
----------------
While it is expected that any "real" deployment at a large company will manage
their users, tenants and other metadata in their existing user systems, a
their users, groups, projects and domains in their existing user systems, a
variety of CRUD operations are provided for the sake of development and testing.
CRUD is treated as an extension or additional feature to the core feature set

Loading…
Cancel
Save