[openstack-dev] [Openstack] [Barbican] Keystone PKI token too much long

Dolph Mathews dolph.mathews at gmail.com
Wed Jul 30 14:57:43 UTC 2014


We recently merged an implementation for GET /v3/catalog which finally
enables POST /v3/auth/tokens?nocatalog to be a reasonable default behavior,
at the cost of an extra HTTP call from remote service back to keystone
where necessary.

Spec:
https://github.com/openstack/keystone-specs/blob/master/specs/juno/get-catalog.rst
Blueprint: https://blueprints.launchpad.net/keystone/+spec/get-catalog
API change:
https://review.openstack.org/#/c/106854/1/v3/src/markdown/identity-api-v3.md
Implementation: https://review.openstack.org/#/c/106893/

I also filed wishlist bug 1350000 ("UUID is a more friendly default token
provider than PKI") recently, based on the developer community's recent
discussions, which Morgan has subsequently raised to the the mailing list
with a survey.

Bug: https://bugs.launchpad.net/keystone/+bug/1350000
Corresponding change of defaults: https://review.openstack.org/#/c/110488/
Survey on the mailing list:
http://lists.openstack.org/pipermail/openstack-dev/2014-July/041474.html

On Tue, Jul 22, 2014 at 4:04 AM, Giuseppe Galeota <giuseppegaleota at gmail.com
> wrote:

>
> ​Dear all,
> have you some good news about the problem related to
> ​the "
> Keystone PKI token too much long​" for Barbican?
>
> Thank you,
> Giuseppe
>
>
>
> 2014-01-31 14:27 GMT+01:00 Ferreira, Rafael <raf at io.com>:
>
>>  By the way, you can achieve the same benefits of uuid tokens (shorter
>> tokens) with PKI by simply using a md5 hash of the PKI token for your
>> X-Auth headers. This is poorly documented but it seems to work just fine.
>>
>>   From: Adam Young <ayoung at redhat.com>
>> Date: Tuesday, January 28, 2014 at 1:41 PM
>> To: "openstack at lists.openstack.org" <openstack at lists.openstack.org>
>> Subject: Re: [Openstack] [Barbican] Keystone PKI token too much long
>>
>>   On 01/22/2014 12:21 PM, John Wood wrote:
>>
>>  (Adding another member of our team Douglas)
>>
>>  Hello Giuseppe,
>>
>>  For questions about news or patches for Keystone's PKI vs UUID modes,
>> you might reach out to the openstack-dev at lists.openstack.org mailing
>> list, with the subject line prefixed with [openstack-dev] [keystone]
>>
>>  Our observation has been that the PKI mode can generate large text
>> blocks for tokens (esp. for large service catalogs) that cause http header
>> errors.
>>
>>  Regarding the specific barbican scripts you are running, we haven't run
>> those in a while, so I'll investigate as we might need to update them.
>> Please email back your /etc/barbican/barbican-api-paste.ini paste config
>> file when you have a chance as well.
>>
>>  Thanks,
>> John
>>
>>
>>  ------------------------------
>> *From:* Giuseppe Galeota [giuseppegaleota at gmail.com]
>> *Sent:* Wednesday, January 22, 2014 7:36 AM
>> *To:* openstack at lists.openstack.org
>> *Cc:* John Wood
>> *Subject:* [Openstack] [Barbican]
>> ​​
>> Keystone PKI token too much long
>>
>>  Dear all,
>> I have configured Keystone for Barbican using this guide
>> <https://github.com/cloudkeep/barbican/wiki/Developer-Guide-for-Keystone>
>> .
>>
>>  Is there any news or patch about the need to use a shorter token? I
>> would not use a modified token.
>>
>> Its a known problem.  You can request a token without the service catalog
>> using an extension.
>>
>> One possible future enhancement is to compress the key.
>>
>>
>>
>>  Following you can find an extract of the linked guide:
>>
>>    - (Optional) Typical keystone setup creates PKI tokens that are long,
>>    do not fit easily into curl requests without splitting into components. For
>>    testing purposes suggest updating the keystone database with a shorter
>>    token-id. (An alternative is to set up keystone to generate uuid tokens.)
>>    From the above output grad the token expiry value, referred to as "x-y-z"
>>
>>  mysql -u rootuse keystone;update token set id="foo" where expires="x-y-z" ;
>>
>>
>>  Thank you,
>> Giuseppe
>>
>>
>> _______________________________________________
>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to     : openstack at lists.openstack.org
>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>
>>
>>  The communication contained in this e-mail is confidential and is
>> intended only for the named recipient(s) and may contain information that
>> is privileged, proprietary, attorney work product or exempt from disclosure
>> under applicable law. If you have received this message in error, or are
>> not the named recipient(s), please note that any form of distribution,
>> copying or use of this communication or the information in it is strictly
>> prohibited and may be unlawful. Please immediately notify the sender of the
>> error, and delete this communication including any attached files from your
>> system. Thank you for your cooperation.
>>
>> _______________________________________________
>> Mailing list:
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to     : openstack at lists.openstack.org
>> Unsubscribe :
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20140730/ac6760ec/attachment.html>


More information about the OpenStack-dev mailing list