<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 2, 2016 at 6:26 PM, Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello! I enjoyed very much listening in on the default token provider<br>
work session last week in Austin, so thanks everyone for participating<br>
in that. I did not speak up then, because I wasn't really sure of this<br>
idea that has been bouncing around in my head, but now I think it's the<br>
case and we should consider this.<br>
<br>
Right now, Keystones without fernet keys, are issuing UUID tokens. These<br>
tokens will be in the database, and valid, for however long the token<br>
TTL is.<br>
<br>
The moment that one changes the configuration, keystone will start<br>
rejecting these tokens. This will cause disruption, and I don't think<br>
that is fair to the users who will likely be shown new bugs in their<br>
code at a very unexpected moment.<br>
<br>
I wonder if one could merge UUID and Fernet into a provider which<br>
handles this transition gracefully:<br>
<br>
if self._fernet_keys:<br></blockquote><div><br><div>This would have to check that there's an active fernet key and 
not just a staging one. You'll want to push out a staging key to all the nodes first to enable fernet validation before pushing out 
the active key to enable token creation. Maybe there's a trick to getting keystone-manage fernet_setup to only setup a staging key, or you just copy that key around.<br></div><div><br></div><div>Also,
 we could have keystone keep track of if there aren't any uuid tokens 
since there's no need to query the database everytime we get an invalid 
token just to see an empty table.<br></div><div><br></div>- Brant<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  return self._issue_fernet_token()<br>
else:<br>
  return self._issue_uuid_token()<br>
<br>
And in the validation, do the same, but also with an eye toward keeping<br>
the UUID tokens alive:<br>
<br>
if self._fernet_keys: </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  try:<br>
    self._validate_fernet_token()<br>
  except InvalidFernetFormatting:<br>
    self._validate_uuid_token()<br>
else:<br>
  self._validate_uuid_token()<br>
<br>
So that while one is rolling out new keystone nodes and syncing fernet<br>
keys, all tokens issued would validated properly, with minimal extra<br>
cost to support both (basically just a number of UUID tokens will need<br>
to be parsed twice, once as Fernet, and once as UUID).<br>
<br>
Thoughts? I think doing this would make changing the default fairly<br>
uncontroversial.<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr">- Brant<br></div></div>
</div></div>