Bug 966514 - Keystone API v3 - requesting token using token authentication fails
Keystone API v3 - requesting token using token authentication fails
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-keystone (Show other bugs)
Unspecified Unspecified
unspecified Severity high
: beta
: 4.0
Assigned To: Adam Young
Jeremy Agee
: TestBlocker, Triaged
Depends On:
  Show dependency treegraph
Reported: 2013-05-23 07:53 EDT by Pavel Sedlák
Modified: 2016-04-26 20:39 EDT (History)
9 users (show)

See Also:
Fixed In Version: openstack-keystone-2013.2-1.el6ost
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-12-19 19:03:13 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Pavel Sedlák 2013-05-23 07:53:38 EDT
When token is requested using old/previous token it always fails with Error 401 and backtrace in keystone.log.

Discovered with openstack-keystone-2013.1.1-1.el6ost and reproduced also with openstack-keystone-2013.1-1.el6 from RDO.

First obtain token:
> $ keystone token-get
> +-----------+----------------------------------+
> |  Property |              Value               |
> +-----------+----------------------------------+
> |  expires  |       2013-05-24T11:36:05Z       |
> |     id    | 774bcddadc4d4c3fbdce42eadc35765d |
> | tenant_id | f07470d9361f477d924c9e0bf0fbfa9e |
> |  user_id  | 033fc7bd70084736b68e6ba919b8152a |
> +-----------+----------------------------------+

Then request new token using first token for authentication:
> localhost:5000 POST /v3/auth/tokens
> '{"auth": {
>    "identity":{
>      "methods":["token"],
>      "token":{"id":"774bcddadc4d4c3fbdce42eadc35765d"}}}}'

This fails with response:
> reply: 'HTTP/1.1 401 Not Authorized\r\n'
> header: Vary: X-Auth-Token
> header: Content-Type: application/json
> header: Content-Length: 116
> header: Date: Thu, 23 May 2013 11:36:17 GMT
> Reply body:
> {u'error': {u'code': 401,
>            u'message': u'The request you have made requires authentication.',
>            u'title': u'Not Authorized'}}

Keystone.log contains:
> 2013-05-23 13:36:17    ERROR [keystone.auth.controllers] 'token_data'
> Traceback (most recent call last):
>   File "/usr/lib/python2.6/site-packages/keystone/auth/controllers.py", line 287, in authenticate_for_token
>     self.authenticate(context, auth_info, auth_context)
>   File "/usr/lib/python2.6/site-packages/keystone/auth/controllers.py", line > 353, in authenticate
>     auth_context)
>   File "/usr/lib/python2.6/site-packages/keystone/auth/plugins/token.py", line 42, in authenticate
>     'user_id', token_ref['token_data']['token']['user']['id'])
> KeyError: 'token_data'
> 2013-05-23 13:36:17  WARNING [keystone.common.wsgi] Authorization failed. The request you have made requires authentication. from

Instead new proper token should be returned based on https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md#the-token-authentication-method .

Example with older API V2 which works:
> localhost:5000 POST /v2.0/tokens
> {"auth":{
>   "token":{"id":"774bcddadc4d4c3fbdce42eadc35765d"},
>   "tenantName":"projB"}}
Comment 2 Adam Young 2013-05-24 11:55:15 EDT
In your initial request, you show a token ID of 774bcddadc4d4c3fbdce42eadc35765d but that is a UUID token.  In Grizzly, the default token implementation if PKI tokens.  A PKI token is much longer, and begins with MII.  Please confirm the configuration of your system is all running the grizzly code.  If you are using UUID tokens, that should have been a deliberate decsion, and you should see an entry in the config file:

token_format = UUID
#token_format = PKI
Comment 3 Adam Young 2013-10-22 15:58:41 EDT
Fix was due to the return code coming from auth_token middleware and was fixed upstream  https://github.com/openstack/keystone/commit/f1f0bbc4b42adeeced224778271f1297b9632b96 which should have been synced in the  2013.1.4 rebase.
Comment 4 Alan Pevec 2013-10-28 09:00:37 EDT
> f1f0bbc4b42adeeced224778271f1297b9632b96 which should have been synced in
> the  2013.1.4 rebase.

This isn't Grizzly-backport candidate, it was only fixed in Havana GA:
Comment 10 errata-xmlrpc 2013-12-19 19:03:13 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.