+1 <br><br><div class="gmail_quote">On Thu, Jun 20, 2013 at 11:37 AM, Dolph Mathews <span dir="ltr"><<a href="mailto:dolph.mathews@gmail.com" target="_blank">dolph.mathews@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><br><div><div class="gmail_extra"><div class="gmail_quote"><div class="im">On Wed, Jun 19, 2013 at 2:20 PM, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>I really want to go the other way on
this: I want token to be very short lived, ideally something like
1 minute, but probably 5 minutes to account for clock skew. I
want to get rid of token revocation list checking. I'd like to
get away from revocation altogether: tokens are not stored in the
backend. If they are ephemeral, we can just check that the token
has a valid signature and that the time has not expired.</div></div></blockquote><div><br></div></div><div>+10</div><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div><div><div><br>
<br>
<br>
<br>
<br>
<br>
On 06/19/2013 12:59 PM, Ravi Chunduru wrote:<br>
</div></div></div><div><div>
<blockquote type="cite">Thats still an open item in this thread.
<div><br>
</div>
<div>Let me summarize once again</div>
<div><br>
</div>
<div>1) Use case for keystone not to re-issue same token for same
credentials</div>
<div>2) Ratelimit cons and service unavailability </div>
<div>3) Further information on python keyring if not going by
keystone re-issue of the tokens.<br>
<br>
<div class="gmail_quote">On Wed, Jun 19, 2013 at 9:16 AM, Yee,
Guang <span dir="ltr"><<a href="mailto:guang.yee@hp.com" target="_blank">guang.yee@hp.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Just
out of curiosity, is there really a use case where
user need to request multiple tokens of the same
scope, where the only difference are the expiration
dates?</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Guang</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
Dolph Mathews [mailto:<a href="mailto:dolph.mathews@gmail.com" target="_blank">dolph.mathews@gmail.com</a>] <br>
<b>Sent:</b> Wednesday, June 19, 2013 7:27 AM</span></p>
<div>
<div><br>
<b>To:</b> OpenStack Development Mailing List<br>
<b>Subject:</b> Re: [openstack-dev] FW:
[Keystone][Folsom] Token re-use</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal"> </p>
<div>
<div>
<p class="MsoNormal">On Wed, Jun 19, 2013 at
1:42 AM, Ali, Haneef <<a href="mailto:haneef.ali@hp.com" target="_blank">haneef.ali@hp.com</a>>
wrote:</p>
<div>
<div>
<p><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">1)</span><span style="font-size:7.0pt;color:#1f497d">
</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Token
Caching is not always going to help.
It depends on the application. E.g
A user writes a cron job to check
the health of swift by listing a
predefined container every 1 minute.
This will obviously create a token
every minute. </span></p>
<p><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">2)</span><span style="font-size:7.0pt;color:#1f497d">
</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Also
I like to understand how rate limiting
is done for v3 tokens. Rate limiting
involves source ip + request pattern.
In V3 there are so many ways to get
the token and the rate limiting
becomes too complex</span></p>
<p><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
</div>
</div>
<div>
<p class="MsoNormal">Rate limit the number
of requests to POST /v2.0/tokens and POST
/v3/auth/tokens</p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Just
for unscoped token, all the
following are equivalent requests.
In case of scoped tokens we have
even more combinations. Rouge
clients can easily mess with rate
limiting by mixing request patterns.
Also rate limiting across regions
may not be possible.</span></p>
<p style="margin-left:1.0in"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">a.</span><span style="font-size:7.0pt;color:#1f497d"> </span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> UserId/Password</span></p>
<p style="margin-left:1.0in"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">b.</span><span style="font-size:7.0pt;color:#1f497d"> </span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> UserName/Password/domainId</span></p>
<p style="margin-left:1.0in"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">c.</span><span style="font-size:7.0pt;color:#1f497d"> </span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">UserName/Password/DomainName</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Thanks</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Haneef</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
Ravi Chunduru [mailto:<a href="mailto:ravivsn@gmail.com" target="_blank">ravivsn@gmail.com</a>]
<br>
<b>Sent:</b> Tuesday, June 18, 2013
11:02 PM<br>
<b>To:</b> OpenStack Development
Mailing List<br>
<b>Subject:</b> Re: [openstack-dev]
FW: [Keystone][Folsom] Token re-use</span></p>
<div>
<div>
<p class="MsoNormal">
</p>
<p class="MsoNormal">I agree we need
a way to overcome these rogue
clients but by rate limiting
genuine requests will get
effected. Then one would need
retries and some times critical
operations gets failed. It beats
the whole logic of being
available.</p>
<div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">About the
keyrings, How do we tackle if
a service is using JSON API
calls and not python clients?</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Thanks,</p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">-Ravi.</p>
<div>
<p class="MsoNormal">On Tue,
Jun 18, 2013 at 6:37 PM,
Adam Young <<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>>
wrote:</p>
<div>
<div>
<div>
<p class="MsoNormal">On
06/18/2013 09:13 PM,
Kant, Arun wrote:</p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The
issue with having
un-managed number
of tokens for same
credential is that
it can be easily
exploited. Getting
a token is one of
initial step
(gateway) to get
access to
services. A rogue
client can keep
creating unlimited
number of tokens
and possibly
create denial of
service attack on
services. If there
are somewhat
limited number of
tokens, then cloud
provider can
possibly use
tokenId based
rate-limiting
approach.</span></p>
</div>
</blockquote>
</div>
<p class="MsoNormal">Better
here to rate limit, then.</p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
<br>
<br>
</p>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Extending
the expiry to some
fixed interval might
be okay as that can
be considered as
continuing user
session similar to
what is seen when a
user keeps browsing
an application while
logged in. </span></p>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Tokens
are resources created by
Keystone. No reason to
ask to create something
new if it is not needed.<br>
<br>
The caching needs to be
done client side. We have
ongoing work using
python-keyring to support
that.<br>
<br>
</p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">-Arun</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<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"">Adam
Young <<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>><br>
<b>Reply-To: </b>OpenStack
Development
Mailing List <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
<b>Date: </b>Friday,
June 14, 2013 3:33
PM<br>
<b>To: </b>"<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>"
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
<b>Subject: </b>Re:
[openstack-dev]
[Keystone][Folsom]
Token re-use</span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""> </span></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif"">On
06/13/2013
07:58 PM, Ravi
Chunduru
wrote:</span></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif"">Hi,
</span></p>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif"">
We are having
Folsom setup
and we find
that our token
table
increases a
lot. I
understand
client can
re-use the
token but why
doesnt
keystone reuse
the token if
client asks it
with same
credentials.. </span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif"">I
would like to
know if there
is any reason
for not doing
so.</span></p>
</div>
<div>
<p class="MsoNormal">
<span style="font-size:10.5pt;font-family:"Calibri","sans-serif""> </span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif"">Thanks
in advance,</span></p>
</div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif"">--
<br>
Ravi</span></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"> </p>
<pre>_______________________________________________</pre>
<pre>OpenStack-dev mailing list</pre>
<pre><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></pre>
</blockquote>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif"">You
can cache the
token on the
client side and
reuse. Tokens
have a an
expiry, so if
you request a
new token, you
extend the
expiry. </span></p>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"> </p>
</div>
<div>
<pre>_______________________________________________</pre>
<pre>OpenStack-dev mailing list</pre>
<pre><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a></pre>
<pre><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></pre>
</div>
<p class="MsoNormal"> </p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></p>
</div>
<p class="MsoNormal"><br>
<br clear="all">
</p>
<div>
<p class="MsoNormal"> </p>
</div>
<p class="MsoNormal">-- <br>
Ravi</p>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></p>
</blockquote>
</div>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
Ravi<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div></div></div><br></div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Ravi<br>