视频讲解：
keystone简单来说是用来做认证的
概念详解：
User:使用Openstack组件的客户端可以是人、服务。系统，任何访问Openstack组件的客户端都需要有一个用户名
Project:
1、是一个人或服务所拥有的资源集合。不同的Project之间资源是隔离的，资源可以设置配额；
2、在一个Project中可以包含多个User,每个User都会根据权限的划分来使用Project中的资源。
3、User访问Project的资源前，必须要与该Project关联，并且指定User在Project下的Role，一个关联即：Project-User-Role
Role:
1、用于权限的划分。通过给User指定Role，使User获得Role对应的操作权限
2、User验证时必须带有Project；
3、Keystone返回给User的Token包含了Role列表，被访问的Services会判断访问它的User和User提供的Token中所包含的Role,及每个role访问资源或者进行操作的权限
Policy:
1、对于Keystone service来说，Policy就是一个JSON文件，默认是/etc/keystone/policy.json。通过配置这个文件，Keystone实现了对User基于Role的权限管理。
2、OpenStack对User的验证除了OpenStack的身份验证以外，还需要鉴别User对某个Service是否有访问权限。Policy机制就是用来控制User对Project(Tenant)中资源的操作权限。
Token:
1、是一个数字字符串，访问资源时需要”亮出”你的令牌。在keystone中主要是引入令牌机制来保护用户对于资源的访问，同时引入PKI（公钥基础实施）对令牌加以保护。
2、Token包含了在指定范围和有效时间内可以被访问的资源。
Credentials:用于确认用户身份的凭证，相当于账号和密码，具体可以是：用户名和密码、用户名和API key、一个 Keystone 分配的身份token
Authentication:
1、确定用户身份的过程。Keystone 服务通过检查用户的 Credential 来确定用户的身份。
2、最开始，使用用户名/密码或者用户名/API key作为credential。当用户的credential被验证后，Kestone 会给用户分配一个 authentication token 供该用户后续的请求使用。
Service:即Openstack中运行的各个组件服务。
Endpoint:
1、是一个可以通过网络来访问和定位某个Openstack service的地址，通常是一个URL
2、Endpoint 分为三类：（走任何一个url都不会使User的权限发生改变，决定User权限的只有Role）
admin url –> 给admin用户使用，Port：35357
internal url –> OpenStack内部服务使用来跟别的服务通信，Port：5000
public url –> 互联网用户可以访问的地址，Port：5000
3、当Nova需要访问Glance服务去获取image 时，Nova通过访问Keystone拿到Glance的endpoint，然后通过访问该endpoint去获取Glance服务。
Catalog：Service和Endpoint的一个集合。每个服务都有一个或者多个endpoint（即可以访问的url地址），即catalog=services+endpoint。
V3新增的概念：
Tenant 重命名为 Project
添加了 Domain 的概念
添加了 Group 的概念
Domain : 表示 project 和 user 的集合，在公有云或者私有云中常常表示一个客户
Group ： 一个domain 中的部分用户的集合
好处：方便管理
组件间通信是基于rest api
keystone功能：1、认证；2、分发rest api
书籍:
云安全考虑：
1、数据安全：云服务提供商需要保护云用户的数据不被窃取或丢失。强加密及密钥管理是云计算系统用以保护数据的一种核心机制。Keystone中引入令牌机制来管理用户对资源的访问，同时引入了PKI(公钥基础实施)对令牌加以保护
2、身份和访问管理安全：有效的身份和访问控制是云平台中必不可少的一个环节。对 于云计算中的用户和服务认证，除了基于风险的认证方法外，还需要注意简单性和易用性。Keystone中通过Policy(访问规则)来做甚于用户角色的访问控制
3、虚拟化安全：虚拟化技术也带来了一些安全问题：如何有效地安全隔离各个虚拟机，以使得数据不会被污染；不同敏感度和安全要求的虚拟机如何共存，以防止安全保护低的虚拟机成为多租户下的瓶颈；虚拟操作系统中缺少安全保护的有效机制以及如何对虚拟机之间的通信进行安全控制。
4、基础设施安全：基础设施安全包括服务器、存储、网络等核心IT基础设施的安全。可信计算池(Trusted Compute Pools)通过对计算节点的硬件以及系统内核进行度量来确定一个可信任计 算节点的集合，可信计算池的引入提高了基础设置的安全性。
Keystone作为OpenStack中一个独立的提供安全认证的模块，主要负责用户的身份认证、令牌管理、提供访问资源的服务目录，以及用户角色的反问控制。
Keystone体系结构：
Domain:域。
1、由特定的项目（Project）来承担。一个域是一组User用户、Group或Project的容器，必须全局唯一。
2、云服务的客户是Domain的所有者，他们可以在自己的 Domain中创建多个Projects、Users、Groups和Roles。
3、通过引入Domain,云服务客户可以对其拥有的多个Project进行统一管理。
User:用户。
1、用户通过Keystone访问OpenStack服务的个人、系统或服务。
2、Keystone通过认证信息（Credential）验证用户的请求，通过验证后用户会得到一个Token令牌（用作后续访问资源的一个通行证，非全局唯一，只需要在域内唯一即可）
Group：用户组。
1、一组Users的容器，可以向容器里添加用户，并直接给用户组分配角色（该用户组中的所有用户就都拥有了Group所拥有的角色权限）
2、通 过引入Group的概念，Keystone实现了对用户组的管理，达到了同时管理一组用户权限的目的。
Project：项目（各个服务中可以访问的资源集合）。
1、我们需要在创建虚拟机时指定某个项目。
2、用户访问项目的资源前，必须具有对该项目的访问权限（或者说是在特定项目下赋予了特定的角色）
3、项目不必全局唯一，只需要在某个域下唯一即可。
Role：角色。
1、只有知道用户所授予的角色才能知道该用户是否有权限访问某资源。
2、用户可以被赋予一个域或则项目内的角色。
3、一个用户被赋予域的角色意味着对域内所有的项目具有相同的角色，而特定项目的角色只具有对特定项目的访问权限。
4、角色可以继承，在一 个项目树下，用于对父项目的访问权限也意味着同时拥有对子项目的访问权限。角色必须全局唯一。
Service：服务，比如Nova、Glance、Cinder等
1、根据User、Tenant、Role一个服务可以确认当前用户是否具有访问其资源的权限。
2、服务对外暴露一个或者多个端点(Endpoint)，用户只有通过这些端点才能访问所需资源或者执行某些操作。
Endpoint：端点。（可以用来访问某个具体服务的网络地址）
1、一般URL细分为：Public、Internal和Admin
2、Public URL是为全局提供的服务端点，Internal URL相对于Public URL来说提供给 内部服务之间的访问，Admin URL提供给系统管理员使用。
Token：令牌（允许访问特定资源的凭证）。
1、Keystone最终目的就是对外提供一个可以访问资源的令牌。
2、通过Credential获取某个项目下的令牌。
Credentials：凭证。用户的用户名和密码。
基于这些核心的概念，Keystone主要提供了 Authentication （认证）、Token（令牌）、 Catalog （目录）和Policy （安全策略，或者说访问控制）4个方面的核心服务。
Authentication :对用户的身份进行验证。认证服务同时提供了与该用户相关的元数据。
Token:验证并管理用于验证身份的令牌。Keystone会颁发给用户两种类型的令牌。一种无明确访问范围的令牌（主要目的是用来保存用户的credential），可以基于此令牌获取有确定访问范围的令牌。用户选择要访问的Project,继而可以获取与Project或者域绑定的令牌，只有通过与某个特定项目或者域相绑定的令牌，才可以访问此项目或者域内的资源。令牌只在有限的时间内有效。
Catalog： Catalog服务对外提供一个服务的查询目录，或者说是每个服务的可访问Endpoint列表。服务目录存有所有服务的Endpoint信息，服务之间的资源访问首先需要获取到该资源的Endpoint信息(通常是一些URL列表)然后才可以根据该信息进行资源访问。从目前的版本来看，Keystone提供的服务目录是与有访问范围的令牌同时返回给用户的。
Policy： 一个基于规则的身份验证引擎，通过配置文件来定义各种动作与用户角色的匹配关系。严格来讲，这部分内容是作为Oslo（OpenStack通用库（Oslo)包含了众多不需要重复发明的”轮子”.当开发者觉得现有的代码中有适合被其他OpenStack项目共用的部分时,就可以申请把这些能用的代码放入oslo-incubator代码库中进行”孵化”.）的一部分进行开发维护，严格来讲已经不是隶属于Keystone项目了。
通过这几个服务，Keystone在用户与服务之间搭起了一道桥梁:用户从Keystone获取令牌以及服务列表；用户访问服务时，发送自己的令牌；相关的服务向Keystone求证令牌的合法性。
Keystone工作流程详解：
1、User用户登录keystone系统，获取一个临时的 unscoped token和catalog服务目录(v3版本登录时，如果没有指定project或domain，获取的临时token没有任何权限，不能查询project或catalog)
2、User通过unscoped token获取所有的project列表。
3、User选定一个project，然后指定一个project重新登录，获取一个scoped token，同时获取服务列表的endpoint，用户选定一个endpoint，在HTTP消息头中携带token，然后发送请求（如果用户知道project name或project id可以直接跳过1、2步，从第3步开始）。
4、User凭借scoped token发送请求到计算服务的endpoint以创建虚拟机，keystone验证token（包括token是否有效，是否有权限创建虚拟机等）成功后，再把请求转发到Nova。
第4步更加详细的解析：
1、消息到达endpoint之后，由服务端（nova）的keystone中间件向keystone发送一个验证token的请求。
2、keystone验证token成功之后，将token对应用户的详细信息，例如：role，username，userid等，返回给服务端（nova）。
3、服务端（nova）完成请求，例如：创建虚拟机。
4、服务端返回请求结果给User。
注意：在上述过程中，常见的会触发两个ERROR
1. 如果User发出的请求中所包含的Token在经过Keystone的验证后无效(Invalid)，则会出发401错误代码。
2. 如果Token有效，但Keystone却不能提供服务，则会返回503错误代码。
除了keystoneclient之外，还涉及另外一个子项目keystonemideeleware。
keystonemiddleware介绍：
1、是Keystone提供的对令牌合法性进行验证的中间件。
2、比如，客户端访问Keystone提供的 资源时提供了 PKI类型（PKI是一种遵循标准的利用公钥加密技术为电子商务的开展提供一套安全基础平台的技术和规范。）的令牌类型，不必每次都需要经过Keystone服务来验证令牌的合法性，通常可以在中间件上进行验证（当然这就需要中间件上已经缓存了相关的证书与秘钥以对令牌进行签名认证。）
3、如果你是PKI类型的令牌，则需要通过Keystoneauth获得一个与Keystone服务连接的session，通过调用Keystone服务提供的API来验证令牌的合法性。
keystoneclient、keystoneauth、keystonemiddleware之间的关系
a、keystoneauth是核心组件,大部分openstack需要验证的的组件都依赖它里面有
1、基础的数据结构
2、http访问使用的requests的session由keystoneauth封装
b、keystoneclient应该是工具组件、依赖keystoneauth
1、部分keystoneclient的代码转移到keystoneauth1中了
2、里面写好了v2和v3接口的client，并定义了keystone的异常
c、keystonemiddleware应该是个二次封装的组件、依赖keystoneauth
1、各个openstack服务和keystone通信用的（不是用户和keystone通信用的,用户和keystone通信时靠keystoneclient）
2、生成、校验、缓存token的代码都写在里面。
Keystone项目本身，除了后台的数据库外，主要包括一个处理RESTful请求的API服务进程。这些API涵盖了 Identity、 Token、Catalog和Policy等Keystone提供的各种服务，这些不同服务所能提供的功能则分别由相应的后端Driver （Backend Driver）实现。
V2与V3不同版本API的区别：
1、V3 API在V2的基础上引入了域（Domains）和用户组(Groups)的概念。
2、域在项目（Project或者说Tenant）之上，一个域中可以包含多个项目。
3、域的引入可以让一个用户更好地管理自己的资源。
4、如果用户被赋予域管理员的权限，那么该用户就可以创建属于域的User/Groups,定义用户在该域内的角色。
5、一个域的管理员权限只限定于此域，他不对 其他域享有相同的权限，这样的设计很好地隔离了各个终端云消费者，而在V2中，管理员这个角色是全局的，也就是说只要你定义了一个管理员用户，那 么该用户是全局有效而非只针对某个项目而言。
6、组是用户的集合，有了组之后，域管理员就无需针对单个的用户来定义其角色了，它可以直接定义一个组所对应的角色，而这个组中的所有用户都具有该角色。
7、域与角色名需要在这个云环境下唯一，而用户、项目以及组则只需在该域内唯一即可。
8、V3API中令牌信息可以不直接暴露于HTTP URL中，令牌ID都是保存在请求Header域”X-Subject-Token”中。相对于V2的实现，从某种意义上来说，提高了系统的安全性，避免了令牌直接暴露在HTTP主体（Body） 中
Keystone源码结构：
keystone：
assignment -用户角色授权
auth -用户认证模块
catalog -提供一个可以访问的服务目录
cmd -命令行支持
contrib -扩展的API实现
credential -用户秘钥管理
endpoint_policy – 基于 endpoint 的 policy 管理
federation -提供联合身份管理
identity -用户身份管理
middleware – WSGI 中间件
oauthl -提供对 OAuthl 支持
policy -用户自定义Policy配置
resource -管理项目和域
revoke -回收消息管理
token -令牌管理模块
trust -提供访问权限代理
v2_crud -己弃用的V2的CRUD操作
version -当前API版本信息
keystone目录下并没有其他项目那样有一个专门的api子目录来针对各种Keystone API 进行实现，而是基本上由针对Identity等不同服务的子目录组成，而且这些子目录下的代码结 构也基本保持一致。
下面以Catalog服务为例：基本都有三个文件，routers.py定义路由规则，通过这些规则，可以将每个API请求路由到 controllers.py 中定义的具体 Controller； core.py 则定义了 Manager 类与 Driver 类, Manager负责基于不同的Backend Driver对请求进一步处理。Driver层与Manager层之间的关系
keystone架构：
一、Keystone API:Keystone API与Openstack其他服务的API类似，也是基于ReSTFul HTTP实现的。Keystone API划分为Admin API和Public API：
1、Public API不仅实现获取版本以及相应扩展信息的操作，同时包括获取Token以及Token租户信息的操作；
2、Admin API主要提供服务开发者使用，不仅可以完成Public API的操作，同时对User、Tenant、Role和Service Endpoint进行管理操作。
二、Router：Keystone Router主要实现上层API和底层服务的映射和转换功能，包括四种Router类型。
1、 AdminRouter
负责将Admin API请求映射为相应的行为操作并转发至底层相应的服务执行；
2、PublicRouter
与AdminRouter类似；
3、 PublicVersionRouter
对系统版本的请求API进行映射操作；
4、AdminVersionRouter
与PublicVersionRouter类似。
三、Services：Keystone Service接收上层不同Router发来的操作请求，并根据不同后端驱动完成相应操作，主要包括四种类
1、Identity Service提供关于用户和用户组的授权认证及相关数据。
2、Resouse Service提供关于projects和domains的数据 。
3、Assignment Service提供role及role assignments的数据
4、Token Service提供认证和管理令牌token的功能，用户的credentials认证通过后就得到token。
5、Catalog Service提供service和Endpoint相关的管理操作（service即openstack所有服务，endpont即访问每个服务的url）。
6、Policy Service提供一个基于规则的授权驱动和规则管理。
四、Backend Driver：Backend Driver具有多种类型，不同的Service选择不同的Backend Driver。
各种Backend Driver代表着不同的后端实现方式（SQL、KVS （Key-Value Store）、 LDAP等）,其他在Keystone中还用到的有Template （可以理解为一种特殊 的KVS实现）、MemCache （高速缓冲存储系统）等。
1、SQL：利用SQLAlchemy做数据的持久化。
2、KVS：通过主键查询的方式可以极大地支持海量数据存储，被广泛应用于缓存、搜索引擎等领域。Keystone中KVS则主要结合缓存来实现数据的存储。
3、LDAP：轻量目录访问协议，以树状的层次结构来存储数据。
4、Template：主要用在服务目录中，通过模板的方式支持用户自定义一个当前系统环境 下可用的服务目录。
keystone启动过程：
使用Devstack进行OpenStack部署时，默认是釆用Apache/mod wsgi的方式进行部署。 在新版本中，除了釆用mod wsgi外，还支持Apache/mod_proxy_uwsgi的方式进行部署。源码中均有支持两种部署的默认配置文件。
Keystone是作为Apache的一个模块随Apache服务的启动而启动的，此时，使用screen 进行开发调试时，我们就需要通过重启Apache服务来运行新的Keystone代码。
为了能够通过Apache访问到Keystone的WSGI应用，这里使用了 mod wsgi (https://code.google.eom/p/modwsgi/ ),并在/etc/apache2/sites-available/keystone.conf 文件中进行了相应的配置。
这里开启了两个TCP的访问端口 5000与35357。按照官方的解释，5000是公用端口， 35357则是管理端口。V3 API出现之前， Keystone定义了一些只有管理员才可以调用的API，V3 API出现出后，这样的操作完全可以有Policy去管控。与之对应的是开启了两个独立的 Virtual Host。
WSGI 脚本/usr/local/bin/keystone-wsgi-admin 就是 Keystone 启动脚本，所做的核心工作包括配置参数的注册、数据库连接的初始化(默认的数据库引擎为SQLite),以及 加载各种Backend Driver等。
为了解决相互依赖的问题，Keystone通过 keystone.common.dependency.resolve_fiiture_dependencies()方法来解决。
Keystone的三种认证方式：
1、基于令牌：如果令牌在authenticate_for_token(self,request,auth=None)的参数auth（第二个参数auth就是我们的curl（URL语法）请求中的传入参数）中，则通过令牌信息来完成认证，剥离HTTP请求Header中的令牌信息，进行哈希计算并与数据库中保存的令牌值进行比对以确认是否有效。令牌在此的作用等效于用户名和密码。
2、外部用户：如果上下文信息context中包含外部用户“REMOTE_USER”信息，认证该外部用户的关联项目以及角色的合法性，并用自定义的方式进行认证。
3、本地认证：默认方式，验证用户名与密码。本地认证核心的操作是通过Backend Driver去做密码的校验，就是对传入明文做一次 SHA512的哈希操作，再与数据库中存放的散列之后的密码进行比对。
4、OAuth1：一种通过OAuthl协议，实现访问权限代理的认证方式，以及以 mapped认证方式对federation功能提供支持。
扩展：OAuth协议旨在为⽤户资源的授权访问提供⼀个安全，开放的标准。OAuth协议并不需要触及⽤户的账户信息(⽤户名和密码)，通过不同类型的token，便可以让平台商完成针对第三方应用的用户信息访问授权。
令牌的生成方式：
校验完成之后会接着检查该用户、域、项目是否可用，过滤掉不需要返回给用户的数据， 并调用Catalog API构造服务目录，最后就是通过具体的Backend去生成令牌。令牌可以有4种生成方式，默认的是使用UUID的方式，之后的版本将会由Fernet令牌取代。
1、UUID：调用Python库函数来生产一个随机的UUID （通用唯一识别码）作为令牌的ID。
2、PKIZ：使用OpenSSL对用户相关信息进行签名，签名后的格式为DER,并以此来生成令牌ID。
3、PKI：使用OpenSSL对用户相关信息进行签名，与PKIZ不同的是生成的签名格式为 PEM。
4、Ferent token：基于Fernet （一种对称加密算法）的对用户信息进行加密而生成的令牌，与用户相关的所有的认证信息都保存在令牌中，故令牌本身就包含了所有的信息，也因此Fernet令牌无需持久化。
扩展：openssl是web安全通信的基石，openssl是SSL的实现版，另外openssl还包含了公钥私钥的生成、摘要生成等各种工具。
在Folsom版本以前，生成令牌ID的方法只有UUID这一种方式。生成的令牌保存在 Keystone的后台数据库中，同时通过网络传给客户端。Keystone在拿到这些信息之后将会提取令牌ID和后台数据库中的值进行比 较以验证请求的合法性。但这样做的问题在于同时大量客户端并发请求的情况下， Keystone的性能将会是一个大的瓶颈。因为每个请求都需要和Keystone进行交互以对令牌的 合法性进行校验；除此之外，如果令牌被无意泄露或者窃取，也将会是一个问题。
于是PKJ系统在之后的版本中被引入，Keystone会利用PKI对令牌相关的数据进行签名，而每一个服务端点会保存一份签名公钥证书、CA公钥证书以及证书吊销列表，这样即可以进行本地校验而无需与Keystone频繁交互。
验证过程：
1、客户端发送用户名密码信息到Keystone进行验证。Keystone校验用户名密码以及项 目信息合法之后用签名私钥对令牌元数据进行签名以生成令牌。
2、令牌通过网络发送到客户端，令牌同时缓存在客户端。
3、客户端发送API请求到服务端点，服务端点提取令牌信息，用本地存放的签名公钥证书进行验签。
4、服务端点处理合法的请求，拒绝验证未通过的请求。