格式
3.1Keystonetoken几种格式的历史
用户可能奇怪为什么Keystone提供多种token格式。
为了便于用户理解其中的原因，我们提供了Keystone几种token格式演进的简要历史。
早期Keystone支持UUIDtoken，这是一种由32位字符组成的字符串和不携带信息的token，用于认证和授权。
UUIDtoken具有小巧、易于使用以及加入curl命令简单的优点，缺点是未携带足够的信息用于本地认证。
OpenStack服务必须将该token发送给Keystone服务以确定是否具有权限，这将导致OpenStack的任何动作都要与Keystone交互，同时Keystone成为OpenStack的瓶颈。
在尝试解决UUIDtoken所遇到问题的过程中，Keystone团队创建了一个新的token格式——PKItoken。
该token包含了用于本地认证的信息，也包括服务目录。
另外，PKItoken是经过签名的，服务可以缓存使用该token，直到它到期或者被撤销。
PKItoken可以减少Keystone服务的负载，但是缺点是该token文件很大。
PKItoken很容易达到8KB，使该token很难适合HTTP消息头。
许多Web服务器在没有重新配置的情况下不能处理8KB的HTTP消息头。
另外，该token很难在cURL命令中使用，用户体验很差。
这些缺点都可以缓和，但是需要额外的代价。
Keystone团队试验了一种经过压缩的PKItoken变体，这种格式称为PKIz。
不幸的是，OpenStack社区反馈该token仍然太大。
Keystone团队重新设计提出一个新的token格式，称为token。
token很小（大概255个字符），但是包含足够的信息用于本地认证。
该token有另外一个重要的优点，它包含了足够的信息，Keystone不需要在token数据库中存储token数据。
33 Keystone的早期token格式有一个最让人厌烦的一面——需要持久地存入数据库。
随着时间的推移，数据库会填满token并影响Keystone的性能。
为了保持OpenStack环境运行，OpenStack用户需要不断地清理Keystonetoken数据库。
token的缺点是用于加密token的对称加密密钥需要分发和旋转。
OpenStack用户需要提出一种处理这些问题的方法。
然而，相比其他token格式需要清理Keytonetoken数据库，OpenStack用户宁愿处理token的密钥分发问题。
面对如此多的token，你可能会好奇，OpenStack用户会使用哪一种。
幸运的是，OpenStack社区执行用户调查（链接为：/results/SMLX589JF8/）来获取这种信息。
UUIDtoken是目前最受欢迎的格式，如图3-1所示。
但是请注意，这篇调查是在OpenStackJuno版本时间内进行的，而且也不包括tokens，因为它们直到Kilo版本才被添加。
您使用哪种token格式？ （样本＝59份） 图3-1：OpenStack用户委员会进行的一项调查表明：UUIDtoken仍然是首选的token格式(Juno版本)本章较详细地描述了Keystone的UUID、PKI和tokens，使读者很好地了解token的几种格式，这有助于了解Keystone。
对于所有的3种token格式，重要的是要注意它们都是不记名token。
这就意味着需要保护所有3个token不泄露，以防止未经授权的访问。
34｜第3章 3.2UUIDtoken Keystone的第一种token格式就是UUIDtoken。
UUIDtoken仅仅是一个随机生成的32位UUID字符串，它们由认证服务发布和验证。
使用hexdigest()方法来确保token由唯一的十六进制数组成。
这种格式使token对url友好，并能在任何非二进制环境中安全传输。
为了保证后续验证，一个UUIDtoken必须在持久化后端（通常是数据库）保存。
通过简单地发送一个带tokenID的DELETE请求就可以撤销一个UUIDtoken。
注意：token不是真正地从后端删除，而是标识为撤销。
由于token只有32个字符，它在HTTP头的大小为32B。
一个典型的UUIDtoken如下所示： 468da447bd1c4821bbc5def0498fd441 当使用curl命令访问Keystone时，UUIDtoken非常小，也很简单。
正如上面提到的，该token格式的缺点是Keystone会成为瓶颈，因为当Keystone需要验证token时会产生巨大的通信量。
返回UUIDtoken的方法相对简单。
下面显示了该方法，也可以在GitHub上找到（/OpenStack/Keystone/blob/master/Keystone/token/providers/uuid.py）。
def_get_token_id(self,token_data):returnuuid.uuid4().hex 3.3PKItoken Keystone的第2种支持的格式是PKItoken格式。
在PKI格式中，token包含了从Keystone中接收的全部的验证响应。
这就意味着该token里面有大量的信息，例如：发布时间、过期时间、用户标识、项目、用户的域和角色信息、服务目录和其他的信息。
所有这些信息由一个JSON文档消息体标识，然后该消息体用cryptographicmessagesyntax签名。
PKIz格式就是使用zlib压缩算法压缩签名的消息体得到的。
一个JSONtoken消息体格式的例子可以在Keystone的文档中找到，重复如下： {"token":{"domain":{"id":"default","name":"Default"},"methods":["password"], token格式｜35 "roles":[{"id":"c703057be878458588961ce9a0ce686b","name":"admin"} ],"expires_at":"2014-06-10T21:52:58.852167Z","catalog":[ {"endpoints":[{"url":"http://localhost:35357/v2.0","region":"RegionOne","interface":"admin","id":"29beb2f1567642eb810b042b6719ea88"},{"url":"http://localhost:5000/v2.0","region":"RegionOne","interface":"internal","id":"87057e3735d4415c97ae231b4841eb1c"},{"url":"http://localhost:5000/v2.0","region":"RegionOne","interface":"public","id":"ef303187fc8d41668f25199c298396a5"}],"type":"identity","id":"bd7397d2c0e14fb69bae8ff76e112a90","name":"Keystone" }],"extras":{},"user":{ "domain":{"id":"default","name":"Default" },"id":"3ec3164f750146be97f21559ee4d9c51","name":"admin"},"audit_ids":["Xpa6Uyn-T9S6mTREudUH3w"],"issued_at":"2014-06-10T20:52:58.852194Z"}} 正如上面所示的JSON，该token包含一个服务所需要的一切，关于用户、域、项目 以及决定用户对于一个特殊的OpenStack服务操作是否授权的角色信息。
因此，服务 能够缓存该token，而且可以本地做授权决定，这样就不用在每一次授权请求时连接 36｜第3章 Keystone服务了。
为了通过HTTP传输PKItoken，签名的JSON文档是做了一些较小修改的base64编码。
这里显示一个token在传输中的样例的缩写形式： MIIDsAYCCAokGCSqGSIb3DQEHAaCCAnoEggJ2ew0KICAgICJhY2QogICAgICAgI...EBMFwwVzELMAkGA1UEBhMCVVMxDjAMBgNVBAgTBVVuc2V0MCoIIDoTCCA50CAQExCTAHBgUrDgMQ4wDAYDVQQHEwVVbnNldDEOMAwGA1UEChM7r0iosFscpnfCuc8jGMobyfApz/dZqJnsk4lt1ahlNTpXQeVFxNK/ydKL+tzEjg 注意：在catalog中只有一个endpoint，对于一个基本的token，即使这样，token也能达到大约1700B。
在拥有几个endpoint和服务的大型部署中，PKItoken的大小会快速地超过大多数Web服务器的默认HTTP头限制——8KB。
即使在压缩之后，PKIztoken的大小没有减少到足够缓和这些问题。
实际上，合成的PKIztoken比PKItoken大约小了10%。
尽管PKI和PKIz可以被缓存，它们也存在一些缺点。
很难配置Keystone来使用这种类型的token，因为它们实际上应该使用由一个可信的证书机构颁发的证书。
而且，它们非常大，可能会引起其他OpenStack服务出现问题。
它们的尺寸也会破坏Web性能工具，在curl命令中使用它们也十分困难。
另外，在实践中，为了创建撤销列表或其他类似的目的，Keystone服务通常必须在持久化后端存储这些token。
结果是用户将一直担心，频繁地刷新Keystonetoken数据库，可能会使性能变差。
一旦困难部分——所有的证书创建完成了，生成PKItoken就不那么复杂了。
返回PKItoken方法的关键部分说明如下注1： def_get_token_id(self,token_data):try:token_json=jsonutils.dumps(token_data,cls=utils.PKIEncoder)token_id=str(cms.cms_sign_token(token_json,CONF.signing.certfile,CONF.signing.keyfile))returntoken_id exceptenvironment.subprocess.CalledProcessError:LOG.exception(_LE('Unabletosigntoken'))raiseexception.UnexpectedError(_('Unabletosigntoken.')) 3.4token 最新的Keystonetoken格式是token格式。
token格式尝试对前几种token格式以各种方式进行改进。
首先，它非常小，通常是255个字符，这比UUIDtoken大，但远比PKI小注
2。
token同样包含足够的信息，这样它不用持久地 注1：/openstack/keystone/blob/master/keystone/token/providers/pki.py 注2：/the-anatomy-of-openstack-keystone-token-formats/ token格式｜37 存储在Keystonetoken数据库中。
相反，该token有足够的信息来生成其余需要的信息，如用户在项目中拥有的角色。
在大规模OpenStack部署中，巨大数量的token数据存储被认为是性能降低的关键因素，况且还有频繁地刷新持久化token数据库注3的需求。
token包含一个数量很小的信息，例如用户标识符、项目标识符、token过期信息和其他审计信息。
token使用对称密钥签名以防止篡改。
token的使用与UUIDtoken的工作流一样。
因此，token必须由Keystone验证，与UUIDtoken的验证过程相似，这与PKItoken形成了对比。
一个复杂因素是token使用对称密钥进行签名，同时这些密钥需要分发到各种各样的OpenStackregions。
另外，这些密钥需要被翻转。
在当前的版本中，由于token还在改进，在这个时间点上尚未提供关于该token的大量细节。
取而代之的是，我们向用户推荐一些在线资源，我们预期，基于真实世界的使用token和旋转注4对称密钥的经验将会更新。
Keystone为设置对称加密密钥提供了一个配置工具，可以通过调用下面的命令来执行： $Keystone-manage_setup 另外，使用下面的命令，该密钥将被周期性地循环： $Keystone-manage_rotate 为了加以说明，创建一个项目范围的token的关键环节如下所示。
为了提高可读性，该样例与源码有些偏差。
创建token的第一步是将各种数据安全地转换为字节，然后序列化token内容，签名，并且使URL安全注
5。
defcreate_token(self,user_id,expires_at,audit_ids,methods=None,domain_id=None,project_id=None,trust_id=None,federated_info=None): b_user_id=cls.attempt_convert_uuid_hex_to_bytes(user_id)methods=auth_plugins.convert_method_list_to_integer(methods)b_project_id=cls.attempt_convert_uuid_hex_to_bytes(project_id) 注3：/#/c/130050/33/specs/kilo/klwt.rst,-tokens/,and/benchmarking-openstack-keystone-tokenformats/ 注4：/?
p=133,/blog/?
p=648,and/blog/?
p=665 注5：/openstack/keystone/blob/master/keystone/token/providers//token_formatters.py 38｜第3章 expires_at_int=cls._convert_time_string_to_int(expires_at)b_audit_ids=list(map(provider.random_urlsafe_str_to_bytes,audit_ids)) payload=(b_user_id,methods,b_project_id,expires_at_int,b_audit_ids)serialized_payload=msgpack.packb(payload)token=urllib.parse.quote(self.crypto.encrypt(serialized_payload))returntoken 一个典型的token如下： kec-0ytpGnMZDBLG9hA7Hr9qfvdZDHjsak39YN98HXxoYLIqVm19Egku5YR3wyI7heVrOmPNEtmr-fIM1rtahudEdEAPM4HCiMrBmiA1Lw6SU8jc2rPLC7FK7nBCia_BGhG17NVHuQu0S7waA306jyKNhHwUnpsBQ%3D token通过简单地执行与创建token相同的步骤来验证，但是过程相反。
从未引用过的安全URL字节开始，然后解压消息体。
之后就是简单地检查消息体的不同部分，特别是对于expires_at字段以及类似的事情。
defvalidate_token(self,token): token=urllib.parse.unquote(six.binary_type(token))serialized_payload=self.crypto.decrypt(token)payload=msgpack.unpackb(serialized_payload) user_id=cls.attempt_convert_uuid_bytes_to_hex(payload[0])methods=auth_plugins.convert_integer_to_method_list(payload[1])project_id=cls.attempt_convert_uuid_bytes_to_hex(payload[2])expires_at_str=cls._convert_int_to_time_string(payload[3])audit_ids=list(map(provider.base64_encode,payload[4])) return(user_id,methods,project_id,expires_at_str,audit_ids) 3.5小贴士、常见问题以及解决方法 本节描述了在使用不同类型的Keystonetoken格式时出现的一些常见的陷阱，同时提供了故障排除的方法以解决这些问题。
3.5.1UUIDtoken的认证操作性能降低 经过长时间使用UUIDtoken之后，操作员可能开始注意到Keystone的认证性能开始严重下降、CPU使用率增长以及响应时间延迟。
这通常是由巨大的Keystone的持久化token后端导致的，因为它存储了许多token。
因此，需要在持久化存储中查询tokenID的认证请求，这会花费非常长的时间。
如果这种情形发生，可以尝试运行Keystone的工具以清空数据库中旧的token。
$Keystone-managetoken_flush token格式｜39 强烈推荐定期运行该命令。
通常最佳实践是作为一个cron定时任务运行它。
3.5.2使用PKItoken对Swift或Horizon无效？ 自从一个PKItoken包括了整个目录，在目录中大规模部署许多endpoints会使token长度增加以致超出HTTP请求头的限制。
这对于一些像OpenStackSwift和Horizon的项目很成问题。
如果遇到这种情况，有几种可能的办法来解决这个问题。
首先，你可以尝试从PKI切换为PKIz。
使用PKIz会导致压缩，可能使长度减少，从而符合需求。
这个通过从PKItokenprovider改为PKIztokenprovider完成。
这个配置项可以在配置文件的[token]段找到，通过设置 [token]provider=Keystone.token.providers.pkiz.Provider 将其设置为PKIz。
另一个可能的办法是增加Web服务器或Eventlet或两者的最大头长度，这取决于项目中受影响的部分。
应该注意到的是，改变这个值仅仅掩盖了低性能，而且增加阈值不是最终的解决方案。
最后，Keystone已经添加了一个允许PKItoken不包含目录的选项，同时一些OpenStack项目（如Swift）允许它们利用该功能的配置项。
在Swift配置文件的Keystone_auth段中，include_service_catalog可以设置为False。
Swift项目不需要服务目录也可以完美地与Keystone一起运行。
关于配置Swift与Keystone协同工作的更多信息可以在网站/OpenStack/swift/blob/5374ba3a80a5b895542196502eac4d9300ba53d2/doc/source/overview_auth.rst#configuring-swift-to-useKeystone中找到。
40｜第3章
为了便于用户理解其中的原因，我们提供了Keystone几种token格式演进的简要历史。
早期Keystone支持UUIDtoken，这是一种由32位字符组成的字符串和不携带信息的token，用于认证和授权。
UUIDtoken具有小巧、易于使用以及加入curl命令简单的优点，缺点是未携带足够的信息用于本地认证。
OpenStack服务必须将该token发送给Keystone服务以确定是否具有权限，这将导致OpenStack的任何动作都要与Keystone交互，同时Keystone成为OpenStack的瓶颈。
在尝试解决UUIDtoken所遇到问题的过程中，Keystone团队创建了一个新的token格式——PKItoken。
该token包含了用于本地认证的信息，也包括服务目录。
另外，PKItoken是经过签名的，服务可以缓存使用该token，直到它到期或者被撤销。
PKItoken可以减少Keystone服务的负载，但是缺点是该token文件很大。
PKItoken很容易达到8KB，使该token很难适合HTTP消息头。
许多Web服务器在没有重新配置的情况下不能处理8KB的HTTP消息头。
另外，该token很难在cURL命令中使用，用户体验很差。
这些缺点都可以缓和，但是需要额外的代价。
Keystone团队试验了一种经过压缩的PKItoken变体，这种格式称为PKIz。
不幸的是，OpenStack社区反馈该token仍然太大。
Keystone团队重新设计提出一个新的token格式，称为token。
token很小（大概255个字符），但是包含足够的信息用于本地认证。
该token有另外一个重要的优点，它包含了足够的信息，Keystone不需要在token数据库中存储token数据。
33 Keystone的早期token格式有一个最让人厌烦的一面——需要持久地存入数据库。
随着时间的推移，数据库会填满token并影响Keystone的性能。
为了保持OpenStack环境运行，OpenStack用户需要不断地清理Keystonetoken数据库。
token的缺点是用于加密token的对称加密密钥需要分发和旋转。
OpenStack用户需要提出一种处理这些问题的方法。
然而，相比其他token格式需要清理Keytonetoken数据库，OpenStack用户宁愿处理token的密钥分发问题。
面对如此多的token，你可能会好奇，OpenStack用户会使用哪一种。
幸运的是，OpenStack社区执行用户调查（链接为：/results/SMLX589JF8/）来获取这种信息。
UUIDtoken是目前最受欢迎的格式，如图3-1所示。
但是请注意，这篇调查是在OpenStackJuno版本时间内进行的，而且也不包括tokens，因为它们直到Kilo版本才被添加。
您使用哪种token格式？ （样本＝59份） 图3-1：OpenStack用户委员会进行的一项调查表明：UUIDtoken仍然是首选的token格式(Juno版本)本章较详细地描述了Keystone的UUID、PKI和tokens，使读者很好地了解token的几种格式，这有助于了解Keystone。
对于所有的3种token格式，重要的是要注意它们都是不记名token。
这就意味着需要保护所有3个token不泄露，以防止未经授权的访问。
34｜第3章 3.2UUIDtoken Keystone的第一种token格式就是UUIDtoken。
UUIDtoken仅仅是一个随机生成的32位UUID字符串，它们由认证服务发布和验证。
使用hexdigest()方法来确保token由唯一的十六进制数组成。
这种格式使token对url友好，并能在任何非二进制环境中安全传输。
为了保证后续验证，一个UUIDtoken必须在持久化后端（通常是数据库）保存。
通过简单地发送一个带tokenID的DELETE请求就可以撤销一个UUIDtoken。
注意：token不是真正地从后端删除，而是标识为撤销。
由于token只有32个字符，它在HTTP头的大小为32B。
一个典型的UUIDtoken如下所示： 468da447bd1c4821bbc5def0498fd441 当使用curl命令访问Keystone时，UUIDtoken非常小，也很简单。
正如上面提到的，该token格式的缺点是Keystone会成为瓶颈，因为当Keystone需要验证token时会产生巨大的通信量。
返回UUIDtoken的方法相对简单。
下面显示了该方法，也可以在GitHub上找到（/OpenStack/Keystone/blob/master/Keystone/token/providers/uuid.py）。
def_get_token_id(self,token_data):returnuuid.uuid4().hex 3.3PKItoken Keystone的第2种支持的格式是PKItoken格式。
在PKI格式中，token包含了从Keystone中接收的全部的验证响应。
这就意味着该token里面有大量的信息，例如：发布时间、过期时间、用户标识、项目、用户的域和角色信息、服务目录和其他的信息。
所有这些信息由一个JSON文档消息体标识，然后该消息体用cryptographicmessagesyntax签名。
PKIz格式就是使用zlib压缩算法压缩签名的消息体得到的。
一个JSONtoken消息体格式的例子可以在Keystone的文档中找到，重复如下： {"token":{"domain":{"id":"default","name":"Default"},"methods":["password"], token格式｜35 "roles":[{"id":"c703057be878458588961ce9a0ce686b","name":"admin"} ],"expires_at":"2014-06-10T21:52:58.852167Z","catalog":[ {"endpoints":[{"url":"http://localhost:35357/v2.0","region":"RegionOne","interface":"admin","id":"29beb2f1567642eb810b042b6719ea88"},{"url":"http://localhost:5000/v2.0","region":"RegionOne","interface":"internal","id":"87057e3735d4415c97ae231b4841eb1c"},{"url":"http://localhost:5000/v2.0","region":"RegionOne","interface":"public","id":"ef303187fc8d41668f25199c298396a5"}],"type":"identity","id":"bd7397d2c0e14fb69bae8ff76e112a90","name":"Keystone" }],"extras":{},"user":{ "domain":{"id":"default","name":"Default" },"id":"3ec3164f750146be97f21559ee4d9c51","name":"admin"},"audit_ids":["Xpa6Uyn-T9S6mTREudUH3w"],"issued_at":"2014-06-10T20:52:58.852194Z"}} 正如上面所示的JSON，该token包含一个服务所需要的一切，关于用户、域、项目 以及决定用户对于一个特殊的OpenStack服务操作是否授权的角色信息。
因此，服务 能够缓存该token，而且可以本地做授权决定，这样就不用在每一次授权请求时连接 36｜第3章 Keystone服务了。
为了通过HTTP传输PKItoken，签名的JSON文档是做了一些较小修改的base64编码。
这里显示一个token在传输中的样例的缩写形式： MIIDsAYCCAokGCSqGSIb3DQEHAaCCAnoEggJ2ew0KICAgICJhY2QogICAgICAgI...EBMFwwVzELMAkGA1UEBhMCVVMxDjAMBgNVBAgTBVVuc2V0MCoIIDoTCCA50CAQExCTAHBgUrDgMQ4wDAYDVQQHEwVVbnNldDEOMAwGA1UEChM7r0iosFscpnfCuc8jGMobyfApz/dZqJnsk4lt1ahlNTpXQeVFxNK/ydKL+tzEjg 注意：在catalog中只有一个endpoint，对于一个基本的token，即使这样，token也能达到大约1700B。
在拥有几个endpoint和服务的大型部署中，PKItoken的大小会快速地超过大多数Web服务器的默认HTTP头限制——8KB。
即使在压缩之后，PKIztoken的大小没有减少到足够缓和这些问题。
实际上，合成的PKIztoken比PKItoken大约小了10%。
尽管PKI和PKIz可以被缓存，它们也存在一些缺点。
很难配置Keystone来使用这种类型的token，因为它们实际上应该使用由一个可信的证书机构颁发的证书。
而且，它们非常大，可能会引起其他OpenStack服务出现问题。
它们的尺寸也会破坏Web性能工具，在curl命令中使用它们也十分困难。
另外，在实践中，为了创建撤销列表或其他类似的目的，Keystone服务通常必须在持久化后端存储这些token。
结果是用户将一直担心，频繁地刷新Keystonetoken数据库，可能会使性能变差。
一旦困难部分——所有的证书创建完成了，生成PKItoken就不那么复杂了。
返回PKItoken方法的关键部分说明如下注1： def_get_token_id(self,token_data):try:token_json=jsonutils.dumps(token_data,cls=utils.PKIEncoder)token_id=str(cms.cms_sign_token(token_json,CONF.signing.certfile,CONF.signing.keyfile))returntoken_id exceptenvironment.subprocess.CalledProcessError:LOG.exception(_LE('Unabletosigntoken'))raiseexception.UnexpectedError(_('Unabletosigntoken.')) 3.4token 最新的Keystonetoken格式是token格式。
token格式尝试对前几种token格式以各种方式进行改进。
首先，它非常小，通常是255个字符，这比UUIDtoken大，但远比PKI小注
2。
token同样包含足够的信息，这样它不用持久地 注1：/openstack/keystone/blob/master/keystone/token/providers/pki.py 注2：/the-anatomy-of-openstack-keystone-token-formats/ token格式｜37 存储在Keystonetoken数据库中。
相反，该token有足够的信息来生成其余需要的信息，如用户在项目中拥有的角色。
在大规模OpenStack部署中，巨大数量的token数据存储被认为是性能降低的关键因素，况且还有频繁地刷新持久化token数据库注3的需求。
token包含一个数量很小的信息，例如用户标识符、项目标识符、token过期信息和其他审计信息。
token使用对称密钥签名以防止篡改。
token的使用与UUIDtoken的工作流一样。
因此，token必须由Keystone验证，与UUIDtoken的验证过程相似，这与PKItoken形成了对比。
一个复杂因素是token使用对称密钥进行签名，同时这些密钥需要分发到各种各样的OpenStackregions。
另外，这些密钥需要被翻转。
在当前的版本中，由于token还在改进，在这个时间点上尚未提供关于该token的大量细节。
取而代之的是，我们向用户推荐一些在线资源，我们预期，基于真实世界的使用token和旋转注4对称密钥的经验将会更新。
Keystone为设置对称加密密钥提供了一个配置工具，可以通过调用下面的命令来执行： $Keystone-manage_setup 另外，使用下面的命令，该密钥将被周期性地循环： $Keystone-manage_rotate 为了加以说明，创建一个项目范围的token的关键环节如下所示。
为了提高可读性，该样例与源码有些偏差。
创建token的第一步是将各种数据安全地转换为字节，然后序列化token内容，签名，并且使URL安全注
5。
defcreate_token(self,user_id,expires_at,audit_ids,methods=None,domain_id=None,project_id=None,trust_id=None,federated_info=None): b_user_id=cls.attempt_convert_uuid_hex_to_bytes(user_id)methods=auth_plugins.convert_method_list_to_integer(methods)b_project_id=cls.attempt_convert_uuid_hex_to_bytes(project_id) 注3：/#/c/130050/33/specs/kilo/klwt.rst,-tokens/,and/benchmarking-openstack-keystone-tokenformats/ 注4：/?
p=133,/blog/?
p=648,and/blog/?
p=665 注5：/openstack/keystone/blob/master/keystone/token/providers//token_formatters.py 38｜第3章 expires_at_int=cls._convert_time_string_to_int(expires_at)b_audit_ids=list(map(provider.random_urlsafe_str_to_bytes,audit_ids)) payload=(b_user_id,methods,b_project_id,expires_at_int,b_audit_ids)serialized_payload=msgpack.packb(payload)token=urllib.parse.quote(self.crypto.encrypt(serialized_payload))returntoken 一个典型的token如下： kec-0ytpGnMZDBLG9hA7Hr9qfvdZDHjsak39YN98HXxoYLIqVm19Egku5YR3wyI7heVrOmPNEtmr-fIM1rtahudEdEAPM4HCiMrBmiA1Lw6SU8jc2rPLC7FK7nBCia_BGhG17NVHuQu0S7waA306jyKNhHwUnpsBQ%3D token通过简单地执行与创建token相同的步骤来验证，但是过程相反。
从未引用过的安全URL字节开始，然后解压消息体。
之后就是简单地检查消息体的不同部分，特别是对于expires_at字段以及类似的事情。
defvalidate_token(self,token): token=urllib.parse.unquote(six.binary_type(token))serialized_payload=self.crypto.decrypt(token)payload=msgpack.unpackb(serialized_payload) user_id=cls.attempt_convert_uuid_bytes_to_hex(payload[0])methods=auth_plugins.convert_integer_to_method_list(payload[1])project_id=cls.attempt_convert_uuid_bytes_to_hex(payload[2])expires_at_str=cls._convert_int_to_time_string(payload[3])audit_ids=list(map(provider.base64_encode,payload[4])) return(user_id,methods,project_id,expires_at_str,audit_ids) 3.5小贴士、常见问题以及解决方法 本节描述了在使用不同类型的Keystonetoken格式时出现的一些常见的陷阱，同时提供了故障排除的方法以解决这些问题。
3.5.1UUIDtoken的认证操作性能降低 经过长时间使用UUIDtoken之后，操作员可能开始注意到Keystone的认证性能开始严重下降、CPU使用率增长以及响应时间延迟。
这通常是由巨大的Keystone的持久化token后端导致的，因为它存储了许多token。
因此，需要在持久化存储中查询tokenID的认证请求，这会花费非常长的时间。
如果这种情形发生，可以尝试运行Keystone的工具以清空数据库中旧的token。
$Keystone-managetoken_flush token格式｜39 强烈推荐定期运行该命令。
通常最佳实践是作为一个cron定时任务运行它。
3.5.2使用PKItoken对Swift或Horizon无效？ 自从一个PKItoken包括了整个目录，在目录中大规模部署许多endpoints会使token长度增加以致超出HTTP请求头的限制。
这对于一些像OpenStackSwift和Horizon的项目很成问题。
如果遇到这种情况，有几种可能的办法来解决这个问题。
首先，你可以尝试从PKI切换为PKIz。
使用PKIz会导致压缩，可能使长度减少，从而符合需求。
这个通过从PKItokenprovider改为PKIztokenprovider完成。
这个配置项可以在配置文件的[token]段找到，通过设置 [token]provider=Keystone.token.providers.pkiz.Provider 将其设置为PKIz。
另一个可能的办法是增加Web服务器或Eventlet或两者的最大头长度，这取决于项目中受影响的部分。
应该注意到的是，改变这个值仅仅掩盖了低性能，而且增加阈值不是最终的解决方案。
最后，Keystone已经添加了一个允许PKItoken不包含目录的选项，同时一些OpenStack项目（如Swift）允许它们利用该功能的配置项。
在Swift配置文件的Keystone_auth段中，include_service_catalog可以设置为False。
Swift项目不需要服务目录也可以完美地与Keystone一起运行。
关于配置Swift与Keystone协同工作的更多信息可以在网站/OpenStack/swift/blob/5374ba3a80a5b895542196502eac4d9300ba53d2/doc/source/overview_auth.rst#configuring-swift-to-useKeystone中找到。
40｜第3章
声明：
该资讯来自于互联网网友发布，如有侵犯您的权益请联系我们。