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
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