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

2014-07-31 Thread Russell Bryant
On 07/30/2014 10:57 AM, Dolph Mathews wrote:
 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.

Is that really a safe default change to make?  It looks like v3 has
already been marked as stable, and this would be a non
backwards-compatible change to the API.

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-07-31 Thread Morgan Fainberg
On Thursday, July 31, 2014, Russell Bryant rbry...@redhat.com wrote:

 On 07/30/2014 10:57 AM, Dolph Mathews wrote:
  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.

 Is that really a safe default change to make?  It looks like v3 has
 already been marked as stable, and this would be a non
 backwards-compatible change to the API.


This default could be made in keystone client, and the catalog could be
fetched separately (session object can handle it). It would mean new
clients would get the same data without a massive token size, but old
clients would still be compatible. API remains compatible and stable.

Cheers,
Morgan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-07-31 Thread Dolph Mathews
Yes, it's a change in default client-side behavior (the client can
explicitly request ?nocatalog). The default server-side behavior is to
continue returning catalogs in requests unless the client requests
otherwise. Before the client adopts the new default, we need
well-established support in auth_token for fetching catalogs when a service
expects one, but auth_token finds it to be missing from PKI tokens.

On Thu, Jul 31, 2014 at 6:59 AM, Russell Bryant rbry...@redhat.com wrote:

 On 07/30/2014 10:57 AM, Dolph Mathews wrote:
  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.

 Is that really a safe default change to make?  It looks like v3 has
 already been marked as stable, and this would be a non
 backwards-compatible change to the API.

 --
 Russell Bryant

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-07-30 Thread Dolph Mathews
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 135 (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/135
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 giuseppegale...@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 r...@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 ayo...@redhat.com
 Date: Tuesday, January 28, 2014 at 1:41 PM
 To: openst...@lists.openstack.org openst...@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@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 [giuseppegale...@gmail.com]
 *Sent:* Wednesday, January 22, 2014 7:36 AM
 *To:* openst...@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 : openst...@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 : openst...@lists.openstack.org
 Unsubscribe :
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org