On 03/09/2016 01:11 AM, Tim Bell wrote:
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
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 <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
__________________________________________________________________________
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