Re: [openstack-dev] [keystone] Using multiple token formats in a one openstack cloud

[Matt Fischer]

On Wed, Mar 9, 2016 at 7:19 AM, Adam Young  wrote:

> On 03/09/2016 01:11 AM, Tim Bell wrote:
>
>
> From: Matt Fischer < m...@mattfischer.com>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> 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>
> 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
>
>
> So, Fernet does not persist, UUID does.  I would guess that a transition
> plan would involve being able to fall back to a persisted UUID if the
> Fernet validation does not work.
>


When we did this we had a few disadvantages. We also upgraded Keystone to
liberty and switched to apache at the same time. This caused db migrations
and more work for puppet. Also as I mentioned the old kilo keystone
middleware can't figure out what to do when you switch token providers,
either restart services or wait for them to think that their tokens have
expired. Because of this we used ansible scripts to orchestrate the process
including db backups (standard when you upgrade a service for us).

Without this degree of difficulty, the transition should be pretty easy.
You setup the keys ahead of time, change the config file, and restart
keystone. The other services should figure it out. If not, you just do a
rolling restart with ansible of API services. Keystone is down for as long
as this takes and your API services are down until you can bounce them. We
maintain a "safe" list of services to restart (which we usually use for
Rabbit issues) and just ran through that list.

You go back later and remove all the junk you had to do for UUIDs like
cronjobs.

I would recommend testing a "failed" transition as well. We did this in our
lab and documented steps for the fallback process to minimize the risk in
production.

I'd be happy to share all my notes + ansible scripts but they were probably
overly cautious since it included an upgrade which meant DB migrations.
__
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

Re: [openstack-dev] [keystone] Using multiple token formats in a one openstack cloud

[Adam Young]

On 03/09/2016 01:44 AM, Matt Fischer wrote:



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.


It requires a brief outage as you switch the provider over. We stopped 
all but 1 node in the cluster then modified it, we did liberty + 
fernet + apache all at the same time to avoid multiple restarts. As 
for the other services, newer keystone middlewares will realize "hey 
my token doesn't work anymore" and will get a new one. At the time we 
did ours, this was not the case, so we bounced every service that uses 
the middleware. All in all in was a brief outage, basically the length 
of time to upgrade a few packages and restart a service on a single 
node.. My opinion is that it was far less invasive than something like 
upgrading neutron, but the APIs were down for a brief time.


Come to my talk in Austin and we'll cover it a bit more.

Captured it here.  Please update with notes.
https://bugs.launchpad.net/keystone/+bug/1555137





__
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

Re: [openstack-dev] [keystone] Using multiple token formats in a one openstack cloud

[Adam Young]

On 03/09/2016 01:11 AM, Tim Bell wrote:


From: Matt Fischer mailto:m...@mattfischer.com>>
Reply-To: "OpenStack Development Mailing List (not for usage 
questions)" <mailto:openstack-dev@lists.openstack.org>>

Date: Tuesday 8 March 2016 at 20:35
To: "OpenStack Development Mailing List (not for usage questions)" 
<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


So, Fernet does not persist, UUID does.  I would guess that a transition 
plan would involve being able to fall back to a persisted UUID if the 
Fernet validation does not work.





On Tue, Mar 8, 2016 at 9:56 AM, rezroo 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 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


__
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

Re: [openstack-dev] [keystone] Using multiple token formats in a one openstack cloud

[Matt Fischer]

>
>
> 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.
>
>
It requires a brief outage as you switch the provider over. We stopped all
but 1 node in the cluster then modified it, we did liberty + fernet +
apache all at the same time to avoid multiple restarts. As for the other
services, newer keystone middlewares will realize "hey my token doesn't
work anymore" and will get a new one. At the time we did ours, this was not
the case, so we bounced every service that uses the middleware. All in all
in was a brief outage, basically the length of time to upgrade a few
packages and restart a service on a single node.. My opinion is that it was
far less invasive than something like upgrading neutron, but the APIs were
down for a brief time.

Come to my talk in Austin and we'll cover it a bit more.
__
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

Re: [openstack-dev] [keystone] Using multiple token formats in a one openstack cloud

[Tim Bell]

From: Matt Fischer mailto:m...@mattfischer.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday 8 March 2016 at 20:35
To: "OpenStack Development Mailing List (not for usage questions)" 
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 
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 
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

Re: [openstack-dev] [keystone] Using multiple token formats in a one openstack cloud

[Matt Fischer]

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.

On Tue, Mar 8, 2016 at 9:56 AM, rezroo  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  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://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:unsubscribehttp://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

Re: [openstack-dev] [keystone] Using multiple token formats in a one openstack cloud

[Lance Bragstad]

On Tue, Mar 8, 2016 at 10:58 AM, Adam Young  wrote:

> On 03/08/2016 11: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  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?
>>
>
We do have token-less authentication built into keystone, which was
released in Liberty and might help with the service authentication case you
described [0]. Having a keystone node validate multiple token formats is
tough because it requires the token providers to know enough information
about other token formats to confidently say "yes, this is a PKI token" or
"no, this isn't a fernet token". Is the sole idea behind letting the client
pick the token format to get around the service authentication situation?
Is there another case you have that makes sense for a client to pick it's
token format?

[0]
https://github.com/openstack/keystone-specs/blob/master/specs/liberty/keystone-tokenless-authz-with-x509-ssl-client-cert.rst


> Thanks,
>> Reza
>>
>> __
>> 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:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> Theoretically:
>
> Two different Keystone servers could independently issue different token
> formats.  They would need to share a common backend, so that they could all
> be verified online.  PKIZ  could be issued from multiple servers, each
> using different signing certs, so long as all the services got all the
> certs.
>
> Practically:
>
> You'd be insane to do this in production
>
> __
> 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

Re: [openstack-dev] [keystone] Using multiple token formats in a one openstack cloud

[Morgan Fainberg]

This type of configuration is not supported as Matt highlighted. What
problem are you trying to solve with having the multiple token formats?
Before we discuss if it would be a good idea, we need to know what problem
you are solving.

On Tue, Mar 8, 2016 at 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  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://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

Re: [openstack-dev] [keystone] Using multiple token formats in a one openstack cloud

[Adam Young]

On 03/08/2016 11: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 > 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://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

Theoretically:

Two different Keystone servers could independently issue different token 
formats.  They would need to share a common backend, so that they could 
all be verified online.  PKIZ  could be issued from multiple servers, 
each using different signing certs, so long as all the services got all 
the certs.


Practically:

You'd be insane to do this in production
__
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

Re: [openstack-dev] [keystone] Using multiple token formats in a one openstack cloud

[rezroo]

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

Re: [openstack-dev] [keystone] Using multiple token formats in a one openstack cloud

[Matt Fischer]

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  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://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-dev] [keystone] Using multiple token formats in a one openstack cloud

[rezroo]

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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev