Hi Craig, Okay, I will read some documents on how to implement such mechanism. Thanks!
John Craig A Lee <craig.a....@aero.org> 於 2016年6月27日 週一 下午3:38寫道： > All, > > > > This issue of *delegation of trust* (user -> nova -> glance, i.e., > enabling nova to auth to glance on behalf of the user) is a fundamental > capability. This is precisely why PKI *proxy certs* (IETF 3820) were > developed back in the grid era enabling chains of trust to be established > up to a specifiable length. The OAuth approach essentially enables one > step of delegation but is certainly getting more widely used. What’s the > best approach for Keystone, however, is not going to be simple to pin down. > > > > --Craig > > > > *From:* Morgan Fainberg [mailto:morgan.fainb...@gmail.com] > *Sent:* Sunday, June 26, 2016 11:11 PM > *To:* 林自均 <johnl...@gmail.com> > *Cc:* openstack@lists.openstack.org > *Subject:* Re: [Openstack] [Keystone] Source IP address in tokens > > > > > On Jun 26, 2016 19:39, "林自均" <johnl...@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@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 >
_______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
