<div dir="ltr">Hi Steve & Morgan,<div><br></div><div>Thank you for your reply! I see the reasons not to validate tokens with theirs source IP addresses.</div><div><br></div><div>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?</div><div><br></div><div>John</div></div><br><div class="gmail_quote"><div dir="ltr">Morgan Fainberg <<a href="mailto:morgan.fainberg@gmail.com">morgan.fainberg@gmail.com</a>> 於 2016年6月27日 週一 下午2:11寫道：<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr"><br>
On Jun 26, 2016 19:39, "林自均" <<a href="mailto:johnlinp@gmail.com" target="_blank">johnlinp@gmail.com</a>> wrote:<br>
><br>
> Hi all,<br>
><br>
> I have the following scenario:<br>
><br>
> 1. On client machine A, a user obtains an auth token with a username and password.<br>
> 2. The user can use the auth token to do operations on client machine A.<br>
> 3. A thief steals the auth token, and do operations on client machine B.<br>
><br>
> 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!<br>
><br>
> John<br>
><br></p><p dir="ltr">
> _______________________________________________<br>
> Mailing list: <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
> Post to     : <a href="mailto:openstack@lists.openstack.org" target="_blank">openstack@lists.openstack.org</a><br>
> Unsubscribe : <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
></p><p dir="ltr"></p>
<p dir="ltr">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). </p>
<p dir="ltr">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. </p>
<p dir="ltr">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. </p>
<p dir="ltr">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). </p>
<p dir="ltr">Eventually we can work on solving this, but there is a bunch of work needed before it can be worked on/explored. </p>
<p dir="ltr">--Morgan</p>
</blockquote></div>