•Endpoint：接入点。

　　是一个通过网络进行访问的地址，例如访问服务的URL。

　　•Role：角色。

　　角色包含一套访问权限和授权。例如管理员权限admin和普通用户组权限member。

　　下图是一个用户验证过程的流程示例。

▲图1：用户验证流程示例

　　Keystone的主要服务进程

　　Keystone有一组内部服务组成。这些服务包含：

　　•Identity

　　该服务主要提供对身份信息的验证包含用户、租户和角色，以及相关联的元数据。

　　•Token

　　该服务验证并且管理所有的令牌信息。

　　•Catalog

　　该服务提供对所有服务接入点的注册管理。

　　•Policy

　　该服务提供了一个基于角色的授权管理系统及规则管理接口。

　　Keystone主要验证后端简介

　　Gizzly版本中的keystone功能已经非常丰富，提供了多种验证后端以期适应不同的环境需求。所有的后端都可在keystone.conf文件中进行定义。

　　SQL验证后端简介

　　基于SQL的验证后端是通过使用SQLAlchemy进行数据的持久存储。所有的用户帐号、租户以及角色等信息都会被存储在SQL数据库中。例如MySQL，DB2。

　　LDAP后端简介

　　LDAP后端经用户和租户分别存储在单独的子树种。而角色则作为租户的一条记录进行存储。

　　其他验证后端

　　PAM验证后端，是利用当前操作系统的用户管理体系进行帐号验证，提供用户和租户间一对一的关系信息，并且root帐号享用admin的权限。

　　其他验证后端与本文表达内容无关，故不在此进行描述。

　　2) Keystone对LDAP的支持

　　在上节keystone的简介中，我们已经提到，目前keystone已经有对LDAP的支持，并且已经有一个成熟稳定的验证后端可以在实际环境中使用。

　　现有LDAP后端对LDAP服务的需求

　　如果Keystone利用现有的LDAP后端进行账户验证时，LDAP服务需要满足keystone的一些较为严苛的需求，主要几点如下：

　　•用户和租户分别在不同的子树中存储

　　•角色必须作为用户及租户的一个属性记录在相应的子树中

　　•拥有LDAP服务的写权限，并且提前写入各个服务帐号(nova、glance、cinder、neutron、ceilometer等组件)以及各组件所在的服务租户(即service租户)。

　　已有LDAP服务与keystone整合的需求

　　对于目前已经拥有成熟LDAP服务的企业及组织，目前keystone对LDAP的需求过于严苛。对于已有LDAP服务的企业组织，LDAP服务通常已经担负起整个企业组织内部的统一身份验证服务，所以很难为满足keystone的需求进行大规模结构调整。因此对于这些组织来说，其目标要求，通常仅是需要通过已有LDAP验证，减少组织内部用户的系统验证数量及复杂程度，并且要保持各个服务之间的独立性。

　　因此，这类需求的可简要概括如下：

　　•保持OpenStack服务的独立性，即OpenStack的系统服务帐号及某些特定管理员帐号不依赖于已有的LDAP服务

　　•使用只读权限与已有LDAP服务整合，只进行帐号验证