Merge "Update architecture documentation"
This commit is contained in:
commit
24f101737c
|
@ -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.identity.core.TenantController`
|
||||
* :mod:`keystone.identity.core.UserController`
|
||||
* :mod:`keystone.identity.core.RoleController`
|
||||
* :mod:`keystone.assignment.controllers.DomainV3`
|
||||
* :mod:`keystone.assignment.controllers.ProjectV3`
|
||||
* :mod:`keystone.assignment.controllers.RoleV3`
|
||||
|
||||
* Authentication
|
||||
|
||||
* :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`
|
||||
|
||||
* Identity
|
||||
|
||||
* :mod:`keystone.identity.controllers.GroupV3`
|
||||
* :mod:`keystone.identity.controllers.UserV3`
|
||||
|
||||
* Policy
|
||||
|
||||
* :mod:`keystone.policy.controllers.PolicyV3`
|
||||
|
||||
* Token
|
||||
|
||||
* :mod:`keystone.service.TokenController`
|
||||
* :mod:`keystone.token.controllers.Auth`
|
||||
|
||||
* Misc
|
||||
|
||||
* :mod:`keystone.service.ExtensionsController`
|
||||
|
||||
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…
Reference in New Issue