<div dir="ltr">Hi Craig,<div><br></div><div>Okay, I will read some documents on how to implement such mechanism. Thanks!</div><div><br></div><div>John</div></div><br><div class="gmail_quote"><div dir="ltr">Craig A Lee <<a href="mailto:craig.a.lee@aero.org">craig.a.lee@aero.org</a>> 於 2016年6月27日 週一 下午3:38寫道：<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">All,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">This issue of
<i>delegation of trust</i> (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
<i>proxy certs</i> (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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">--Craig<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Morgan Fainberg [mailto:<a href="mailto:morgan.fainberg@gmail.com" target="_blank">morgan.fainberg@gmail.com</a>]
<br>
<b>Sent:</b> Sunday, June 26, 2016 11:11 PM<br>
<b>To:</b> </span><span style="font-size:11.0pt;font-family:"MS Gothic"">林自均</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> <<a href="mailto:johnlinp@gmail.com" target="_blank">johnlinp@gmail.com</a>><br>
<b>Cc:</b> <a href="mailto:openstack@lists.openstack.org" target="_blank">openstack@lists.openstack.org</a><br>
<b>Subject:</b> Re: [Openstack] [Keystone] Source IP address in tokens<u></u><u></u></span></p></div></div><div lang="EN-US" link="blue" vlink="purple"><div>
<p class="MsoNormal"><u></u> <u></u></p>
<p><br>
On Jun 26, 2016 19:39, "<span style="font-family:"Calibri",sans-serif">林自均</span>" <<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>
> _______________________________________________<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>
><u></u><u></u></p>
<p>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).
<u></u><u></u></p>
<p>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.
<u></u><u></u></p>
<p>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.
<u></u><u></u></p>
<p>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).
<u></u><u></u></p>
<p>Eventually we can work on solving this, but there is a bunch of work needed before it can be worked on/explored.
<u></u><u></u></p>
<p>--Morgan<u></u><u></u></p>
</div></div></blockquote></div>