On 05/21/2014 08:59 PM, Clint Byrum wrote:
Excerpts from John Dickinson's message of 2014-05-21 17:23:02 -0700:
On May 21, 2014, at 4:26 PM, Adam Young <ayo...@redhat.com> wrote:

On 05/21/2014 03:36 PM, Kurt Griffiths wrote:
Good to know, thanks for clarifying. One thing I’m still fuzzy on, however, is 
why we want to deprecate use of UUID tokens in the first place? I’m just trying 
to understand the history here...
Because they are wasteful, and because they are the chattiest part of 
OpenStack.  I can go into it in nauseating detail if you really want, including 
the plans for future enhancements and the weaknesses of bearer tokens.


A token is nothing more than a snap shot of the data you get from Keystone 
distributed.  It is stored in Memcached and in the Horizon session uses the 
hash of it for a key.

You can do the same thing.  Once you know the token has been transferred once 
to a service, assuming that service has caching on, you can pass the hash of 
the key instead of the whole thing.
So this would mean that a Swift client would auth against Keystone to get the PKI token, 
send that to Swift, and then get back from Swift a "short" token that can be 
used for subsequent requests? It's an interesting idea to consider, but it is a new sort 
of protocol for clients to implement.

Doesn't this mean that Swift would have to store the token it first
received, so that it can verify that the hash matches the token and to
extract the session information contained within?

It seems like the keystone auth middleware should be able to help with
this quite a bit, and I think it already does, but a pointer to the
documentation on how to make use of it would help close the loop here.

yes, it does:
http://git.openstack.org/cgit/openstack/python-keystoneclient/tree/keystoneclient/middleware/auth_token.py#n863


The call to |cms.cms_hash_token(user_token) ||returns the original value if it is already hashed.| The cached value is then looked up in memcached.

Note the pkiz tokens referenced a couple lines later are the compressed version we referenced earlier.


Actually, you can do that up front, as auth_token middleware will just default 
to an online lookup. However, we are planning on moving to ephemeral tokens 
(not saved in the database) and an online lookup won't be possible with those.  
The people that manage Keystone will be happy with that, and forcing an online 
lookup will make them sad.
An "online lookup" is one that calls the Keystone service to validate a token? 
Which implies that by disabling online lookup there is enough info in the token to 
validate it without any call to Keystone?

Yes, PKI tokens can be validated by the service without phoning back
home to Keystone. However, currently the service must still ask Keystone
for a list of revoked tokens periodically. In the near future that will
morph into a list of token revocation events, which should make the
backend simpler for Keystone to implement. I assume the middleware will
also do most of the heavy lifting there too.

I understand how it's advantageous to offload token validation away from Keystone itself 
(helps with scaling), but the current "solution" here seems to be pushing a lot 
of pain to consumers and deployers of data APIs (eg Marconi and Swift and others).

I tend to agree, though if the middleware implements the caching/hashing
that Adam describes, then it may only be a few changes to the way that
is configured.

Hash is MD5 up through what is released in Icehouse.  The next version of 
auth_token middleware will support a configurable algorithm.  The default 
should be updated to sha256 in the near future.
If a service (like Horizon) is hashing the token and using that as a session 
key, then why does it matter what the auth_token middleware supports? Isn't the 
hashing handled in the service itself? I'm thinking in the context of how we 
would implement this idea in Swift (exploring possibilities, not committing to 
a patch).

The impression I got is that Horizon is a special case, and that most
services would just use the keystone auth middleware directly.

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to