[Openstack] [Keystone] Source IP address in tokens

林自均 johnlinp at gmail.com
Mon Jun 27 07:13:18 UTC 2016


Hi Steve & Morgan,

Thank you for your reply! I see the reasons not to validate tokens with
theirs source IP addresses.

One more question to Morgan: you mentioned that I should use the shortest
life span of tokens (perhaps 1 hour?), but this will make the users type in
their usernames and passwords too often. Let's say if I want to provide a
"Remember me for 30 days" checkbox, is there a better way other than
setting the life span of tokens to 30 days?

John

Morgan Fainberg <morgan.fainberg at gmail.com> 於 2016年6月27日 週一 下午2:11寫道:

>
> 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/20160627/9205f870/attachment.html>


More information about the Openstack mailing list