<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Dec 21, 2013 at 5:19 PM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@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 class="im">On 12/21/2013 04:19 PM, Ryan Lane wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Sat, Dec 21, 2013 at 4:07 PM, Jay Pipes <<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a><br></div><div class="im">
<mailto:<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>>> wrote:<br>
<br>
On 12/21/2013 03:27 PM, Ryan Lane wrote:<br>
<br>
On Thu, Dec 19, 2013 at 9:05 PM, 陈锐 <<a href="mailto:chenrui.momo@gmail.com" target="_blank">chenrui.momo@gmail.com</a><br>
<mailto:<a href="mailto:chenrui.momo@gmail.com" target="_blank">chenrui.momo@gmail.com</a><u></u>><br></div>
<mailto:<a href="mailto:chenrui.momo@gmail.com" target="_blank">chenrui.momo@gmail.com</a><div class="im"><br>
<mailto:<a href="mailto:chenrui.momo@gmail.com" target="_blank">chenrui.momo@gmail.com</a><u></u>>__>> wrote:<br>
<br>
I think you should use UUID token and backend should be sql<br>
or memcache<br>
<br>
<br>
If you want this to work across regions, redis or sql is likely<br>
what you<br>
want (with replication). sql with galera is likely the best<br>
option if<br>
you want to avoid a SPOF for writes.<br>
<br>
<br>
For the identity backend, yes :) But definitely not for the token<br>
backend!<br>
<br>
Really? Why shouldn't the tokens be shared between the regions? Wouldn't<br>
that mean you need to authenticate for each region to get unscoped tokens?<br>
</div></blockquote>
<br>
I don't really see much of a use case for cross-region token sharing, but then again, I might be misunderstanding the use case :)<br>
<br>
We have multiple deployment zones (regions), that share a Keystone identity database, however each zone's Keystone service uses the memcache token backend. Users of the deployment don't know that each deployment zone is authenticating tokens separately, because users simply hit the region's Keystone endpoint (which gives the region's service catalog), and all API calls go to that particular region's endpoints.<br>
<br>
Can you describe the use case for this unscoped token you refer to above? By unscoped, you are referring to "this token may be used to authenticate in multiple regions"? or are you referring to something else?<br>
<br></blockquote><div><br></div><div>For this thread's record:</div><div><br></div><div>A number of us discussed this via IRC. My use case was SSO for a web application that has a unified view of regions and projects. I don't require users to re-authenticate for each region.</div>
<div><br></div><div>For this, I'd like to replicate my tokens across regions, which should work, but will be slow due to the large number of tokens generated by normal use. Some alternatives were the use of PKI tokens, the use of oauth in my web interface, or my web interface enumerating the keystone endpoints, authenticating to each and keeping track of the scoped and unscoped tokens.<br>
</div><div><br></div><div>I'm likely going with the replication approach, and may implement a simple redis token backend since the dogpile code only handles some caching logic.</div><div><br></div><div>Anyway, this is slightly off-topic of the original thread, but I thought it would be good to update the thread in case others need this kind of info.</div>
<div><br></div><div>- Ryan</div></div></div></div>