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 <[email protected]> 於 2016年6月27日 週一 下午2:11寫道： > > On Jun 26, 2016 19:39, "林自均" <[email protected]> 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 : [email protected] > > 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 >
_______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : [email protected] Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
