注:本文内容均来自网络,我只是在此做了一些摘抄和整理的工作,来源均有注明。
0、简介及架构
既然keystone为各个模块提供认证服务,所以各个模块与keystone都有所交互。其中登录认证体现在用户访问各个组件的API时,调用了WSGI框架的authtoken filter,该filter最调用keystoneclient ,最终通过keystone验证token,完成对用户的登录认证。如果认证失败,用户将不能访问该API。
以nova为例,authtoken filter在/etc/paste.ini目录中(如果不熟悉WSGI框架,暂且忽略之)
keystone在openstack的位置如下:
1、基本概念
1. User
User即用户,他们代表可以通过keystone进行访问的人或程序。Users通过认证信息(credentials,如密码、API Keys等)进行验证。
2. Tenant
Tenant即租户,早期版本又称为project,它是各个服务中的一些可以访问的资源集合。例如,在Nova中一个tenant可以是一些机器,在Swift和Glance中一个tenant可以是一些镜像存储,在Quantum中一个tenant可以是一些网络资源。Users默认的总是绑定到某些tenant上,用户访问租户的资源前,必须与该租户关联,并且指定该用户在该租户下的角色。
3. Role
Role即角色,Roles代表一组用户可以访问的资源权限,例如Nova中的虚拟机、Glance中的镜像。Users可以被添加到任意一个全局的 或 租户内的角色中。在全局的role中,用户的role权限作用于所有的租户,即可以对所有的租户执行role规定的权限;在租户内的role中,用户仅能在当前租户内执行role规定的权限。
4. Service
Service即服务,如Nova、Glance、Swift。根据前三个概念(User,Tenant和Role)一个服务可以确认当前用户是否具有访问其资源的权限。但是当一个user尝试着访问其租户内的service时,他必须知道这个service是否存在以及如何访问这个service,这里通常使用一些不同的名称表示不同的服务。在上文中谈到的Role,实际上也是可以绑定到某个service的。例如,当swift需要一个管理员权限的访问进行对象创建时,对于相同的role我们并不一定也需要对nova进行管理员权限的访问。为了实现这个目标,我们应该创建两个独立的管理员role,一个绑定到swift,另一个绑定到nova,从而实现对swift进行管理员权限访问不会影响到Nova或其他服务。
5. Endpoint
Endpoint,翻译为“端点”,我们可以理解它是一个服务暴露出来的访问点,如果需要访问一个服务,则必须知道他的endpoint。因此,在keystone中包含一个endpoint模板(endpoint template,在安装keystone的时候我们可以在conf文件夹下看到这个文件),这个模板提供了所有存在的服务endpoints信息。一个endpoint template包含一个URLs列表,列表中的每个URL都对应一个服务实例的访问地址,并且具有public、private和admin这三种权限。public url可以被全局访问(如http://compute.example.com),private url只能被局域网访问(如http://compute.example.local),admin url被从常规的访问中分离。
6. Token
Token即是信物、令牌,用户通过用户名和密码获取在某个租户下的token,通过token,可以实现单点登录。
7. Credentials
与user关联的认证凭据。一个user可能有一个或多个credential,一个credential与某一个project关联。该术语可以简单的理解为用户和密码。

那什么叫做 User ,Tenant 呢?这里我举个比较好理解的例子。我们去宾馆住的时候,
User | 住宾馆的人 |
Credentials | 身份证 |
Authentication | (认证身份证)宾馆为了拒绝不必要的人进出宾馆,专门设置的机制,只有拥有钥匙的人才能进出 |
Token | 房卡 |
Tenant | 宾馆 |
Service | 宾馆可以提供的服务类别,比如,饮食类,娱乐类 |
Endpoint | 具体的一种服务,比如吃烧烤,打羽毛球 |
Role | VIP 等级,VIP越高,享有越高的权限 |
2、组件
keystone - 运行keystone-admin和keystone-service
keystone-admin - 操作keystone的管理API
keystone-service - 用于验证的,面向用户的API
keystone-manage - 管理keystone的命令行接口
Keystone还包括WSGI中间件以为Nova和Swift提供验证服务。
Keystone使用一个内置的SQLite数据库 - 为验证用户,将来也可能使用一个外部LDAP服务来代替存储证书
中间件(Middleware)
Keystone中间件位于OpenStack服务前面,处理进来的请求验证。中间件的设计遵循如下的规范。
中间件的源代码位于Keystone/middleware。
中间件支持两个接口:WSGI和REST/HTTP。
REST & HTTP API
如果进来一个未经认证的调用,中间件将响应一个401 Unautorized错误。根据每HTTP的标准,它也会返回一个WWW-Authenticate包头以通知调用者支持哪个协议。对于Keystone验证,响应的语法格式如下:
WWW-Authenticate: Keystone uri="url to Keystone server"The client can then make the necessary calls to the Keystone server, obtain a token, and retry the call with the token.
令牌使用 X-Auth-Toke包头传递。
WSGI API(包头)
当成功验证后中间件经为下行的WSGI应用发送如下包头:
X-Identity-Status
提供请求是否被验证的信息。
X-Tenant
提供了租户ID(在Keystone中以URL的形式出现)。在Keysotne转为采用ID/Name模式之前,它为租户提供了对任意遗留实现的支持。
X-Tenant-Id
唯一不变的租户ID。
X-Tenant-Name
唯一但可变的租户名字。
X-User
用于登录的用户名。
X-Roles
分配给用户的角色。
3、访问流程
以创建一个虚拟机(server)为例,结合下图简述下keystone在openstack的访问流程。
1)用户Alice通过自己的户名和密码向keystone申请token,keystone认证用户名和密码后,返回token1
2)Alice通过token1发送keystone查询他所拥有的租户,keystone验证token1成功后,返回Alice的所有Tenant
3) Alice选择一个租户,通过用户名和密码申请token,keystone认证用户名、密码、tenant后,返回token2。(其实1、2步仅仅是为了查询tenant,如果已经知道tenant,可以忽略1、2步)
4)Alice通过token2发送创建server的请求,keystone验证token2(包括该token是否有效,是否有权限创建虚拟机等)成功后,然后再把请求下发到nova,最终创建虚拟机


4、进阶
参考:
- OpenStack 官方文档: http://docs.openstack.org/admin-guide-cloud/content/keystone-concepts.html
- OpenStack Identity(Keystone)身份服务-体系结构与中间件: http://my.oschina.net/amoshuang/blog/83694
- openstack keystone整体架构与功能: http://blog.youkuaiyun.com/wsfdl/article/details/20492343
- OpenStack Keystone的基本概念理解: http://www.cnblogs.com/yuki-lau/archive/2013/01/04/2843918.html
- 【OpenStack】OpenStack的G版Keystone对象模型: http://blog.youkuaiyun.com/lynn_kong/article/details/8564535
- [openstack][G版]keystone源码学习: http://blog.youkuaiyun.com/wangyish201201/article/details/8959104
- openstack policy 鉴权过程分析 : http://blog.chinaunix.net/uid-20940095-id-4144300.html
- 将openstack的Token认证信息存储在memcache中: http://lustlost.blog.51cto.com/2600869/1318642