[Openstack] [Keystone] Source IP address in tokens

Morgan Fainberg morgan.fainberg at gmail.com
Mon Jun 27 06:11:06 UTC 2016


On Jun 26, 2016 19:39, "林自均" <johnlinp at gmail.com> wrote:
>
> Hi all,
>
> I have the following scenario:
>
> 1. On client machine A, a user obtains an auth token with a username and
password.
> 2. The user can use the auth token to do operations on client machine A.
> 3. A thief steals the auth token, and do operations on client machine B.
>
> Can Keystone check the auth token's source IP (which is client machine A
in the above example) to prevent thieves to use it? Does this feature
exist? Or is it a work in progress? Thanks for the help!
>
> John
>
> _______________________________________________
> Mailing list:
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe :
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>

Unfortunately, validating tokens in this way will induce a number of
failures. The user's token is passed through from one service to another
for subsequent actions (e.g. nova talking to glance to get the proper
image).

We are working on changing how AuthZ is handled when it is service to
service (nova to glance or cinder) vs when it is user to service.

While we have had the concept of token binding (requiring an x509 client
cert for example) the above mentioned limitation has made the feature a
non-starter. Generally speaking bearer tokens are known to have this issue
and keystone tokens are bearer tokens.

The best mitigation is to use TLS for communication to the endpoints (user
-> service) and limit the life span of the tokens to the shortest window
possible (making replay attacks significantly more difficult as the tokens
expire quickly).

Eventually we can work on solving this, but there is a bunch of work needed
before it can be worked on/explored.

--Morgan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20160626/1583d1a6/attachment.html>


More information about the Openstack mailing list