我正在configurationGlance来对照Keystone进行身份validation。 它的工作原理，但我不确定如何一些身份validation选项交互。
我从configuration浏览文档开始，但实际上并没有logging任何这些选项。 我find了authentication文档 ，其中讨论了其中的一些，但实际上并不loggingauth_uri 。
OpenStack安装和部署手册中的示例glanceconfiguration如下所示：
[filter:authtoken] paste.filter_factory = keystone.middleware.auth_token:filter_factory service_protocol = http service_host = 127.0.0.1 service_port = 5000 auth_host = 127.0.0.1 auth_port = 35357 auth_protocol = http auth_uri = http://127.0.0.1:5000/ admin_token = 012345SECRET99TOKEN012345
身份validation文档说：
那些以auth_开头的variables指向Keystone Admin服务。 中间件使用该信息来实际询问Keystone关于authentication令牌的有效性。
好的。 那么auth_uri如何与auth_host ， auth_port和auth_protocol ？ 可以简单地提供auth_uri并放弃其他选项吗？ 有没有相应的service_uriconfiguration选项？ 为什么auth_uri中的端口与上述configuration中的service_port对应，而不是auth_port ？
Keystone将端口35357称为“pipe理员”端口，对于我来说，这只对pipe理keystone（创build/删除服务，租户等）是必需的。 一瞥而是将其称为“auth”端口，这表示不同的用途。 端口35357上的服务提供的端口5000上的服务没有提供什么服务？
首先检查： http : //docs.openstack.org/ops/OpenStackOperationsGuide.pdf
看一眼源代码…
tools/migrate_image_owners.py
…是唯一引用auth_uri的文件。
看起来这个variables已经遍布全球，它协助客户端和整个OpenStack中的身份validation令牌处理。 它不是专门用于一目了然的…但它被用于中间件堆栈的实用程序使用。
至于keystone上5000和35357的区别…
http://docs.openstack.org/developer/keystone/api_curl_examples.html有一个非常明确的讨论什么样的API的例子工作，或不。
我对端口5000的理解是，它的具体目的是允许公钥APIauthentication到keystone，所以你不需要公开35357就可以让人们对它进行authentication。
至于为什么每个OpenStack组件里面的auth creds都和keystone绑定在一起…我真的不这么认为。 知道。
不过，我应该指出API v2正在灰飞烟灭。 目前还没有完整的文件logging，它将开始引入Keystone如何运作的一些根本性的改变。