Open Stack

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 <openstack at 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 <openstack at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160308/6448d0c4/attachment.html>