[Openstack] [Keystone] Source IP address in tokens

林自均 johnlinp at gmail.com
Tue Jun 28 01:42:25 UTC 2016


Hi Craig,

Okay, I will read some documents on how to implement such mechanism. Thanks!

John

Craig A Lee <craig.a.lee at 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.fainberg at gmail.com]
> *Sent:* Sunday, June 26, 2016 11:11 PM
> *To:* 林自均 <johnlinp at gmail.com>
> *Cc:* openstack at lists.openstack.org
> *Subject:* Re: [Openstack] [Keystone] Source IP address in tokens
>
>
>
>
> 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/20160628/ca3f91eb/attachment.html>


More information about the Openstack mailing list