From: Matt Fischer <m...@mattfischer.com<mailto:m...@mattfischer.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday 8 March 2016 at 20:35
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [keystone] Using multiple token formats in a one 
openstack cloud

I don't think your example is right: "PKI will validate that token without 
going to any keystone server". How would it track revoked tokens? I'm pretty 
sure that they still get validated, they are stored in the DB even.

I also disagree that there are different use cases. Just switch to fernet and 
save yourself what's going to be weeks of pain with probably no improvement in 
anything with this idea.

Is there any details on how to switch to Fernet for a running cloud ? I can see 
a migration path where the cloud is stopped, the token format changed and the 
cloud restarted.

It seems more complex (and maybe insane, as Adam would say) to do this for a 
running cloud without disturbing the users of the cloud.

Tim

On Tue, Mar 8, 2016 at 9:56 AM, rezroo 
<openst...@roodsari.us<mailto:openst...@roodsari.us>> wrote:
The basic idea is to let the openstack clients decide what sort of token 
optimization to use - for example, while a normal client uses uuid tokens, some 
services like heat or magnum may opt for pki tokens for their operations. A 
service like nova, configured for PKI will validate that token without going to 
any keystone server, but if it gets a uuid token then validates it with a 
keystone endpoint. I'm under the impression that the different token formats 
have different use-cases, so am wondering if there is a conceptual reason why 
multiple token formats are an either/or scenario.


On 3/8/2016 8:06 AM, Matt Fischer wrote:
This would be complicated to setup. How would the Openstack services validate 
the token? Which keystone node would they use? A better question is why would 
you want to do this?

On Tue, Mar 8, 2016 at 8:45 AM, rezroo 
<openst...@roodsari.us<mailto:openst...@roodsari.us>> wrote:
Keystone supports both tokens and ec2 credentials simultaneously, but as far as 
I can tell, will only do a single token format (uuid, pki/z, fernet) at a time. 
Is it possible or advisable to configure keystone to issue multiple token 
formats? For example, I could configure two keystone servers, each using a 
different token format, so depending on endpoint used, I could get a uuid or 
pki token. Each service can use either token format, so is there a conceptual 
or implementation issue with this setup?
Thanks,
Reza

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to