Authenticating v2 token against v3 api fails with error 500

Bug #1212778 reported by Steven Hardy
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Fix Released
Critical
Adam Young

Bug Description

I've been trying to consume a trust as documented in:

https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3-os-trust-ext.md

Using my patch to keystoneclient:

https://review.openstack.org/#/c/39899/

And I find that although the request to v3/auth/tokens fails with the following error:

REQ: curl -i -X POST http://localhost:35357/v3/auth/tokens -H "User-Agent: python-keystoneclient" -H "Content-Type: application/json" -H "X-Auth-Token: <ADMIN TOKEN>"
REQ BODY: {"auth": {"identity": {"methods": ["token"], "token": {"id": <ADMIN TOKEN>}}, "scope": {"OS-TRUST:trust": {"id": "7b6d5a4ee39645e3aba11c535e5069f3"}}}}

RESP: [500] {'date': 'Thu, 15 Aug 2013 17:18:08 GMT', 'content-type': 'application/json', 'content-length': '151', 'vary': 'X-Auth-Token'}
RESP BODY: {"error": {"message": "An unexpected error prevented the server from fulfilling your request. 'token'", "code": 500, "title": "Internal Server Error"}}

Request returned failure status: 500
Traceback (most recent call last):
  File "trust_reproducer.py", line 61, in <module>
    c_trust.authenticate()
  File "/opt/stack/python-keystoneclient/keystoneclient/httpclient.py", line 458, in authenticate
    resp, body = self.get_raw_token_from_identity_service(**kwargs)
  File "/opt/stack/python-keystoneclient/keystoneclient/v3/client.py", line 165, in get_raw_token_from_identity_service
    '%s' % e)
keystoneclient.exceptions.AuthorizationFailure: Authorization failed: An unexpected error prevented the server from fulfilling your request. 'token' (HTTP 500)

I've replaced the real token with <ADMIN TOKEN> above.

In the keystone log output I see this:

2013-08-15 18:36:57.129 4171 ERROR keystone.common.wsgi [-] 'token'
2013-08-15 18:36:57.129 4171 TRACE keystone.common.wsgi Traceback (most recent call last):
2013-08-15 18:36:57.129 4171 TRACE keystone.common.wsgi File "/opt/stack/keystone/keystone/common/wsgi.py", line 240, in __call__
2013-08-15 18:36:57.129 4171 TRACE keystone.common.wsgi result = method(context, **params)
2013-08-15 18:36:57.129 4171 TRACE keystone.common.wsgi File "/opt/stack/keystone/keystone/auth/controllers.py", line 287, in authenticate_for_token
2013-08-15 18:36:57.129 4171 TRACE keystone.common.wsgi self.authenticate(context, auth_info, auth_context)
2013-08-15 18:36:57.129 4171 TRACE keystone.common.wsgi File "/opt/stack/keystone/keystone/auth/controllers.py", line 343, in authenticate
2013-08-15 18:36:57.129 4171 TRACE keystone.common.wsgi auth_context)
2013-08-15 18:36:57.129 4171 TRACE keystone.common.wsgi File "/opt/stack/keystone/keystone/auth/plugins/token.py", line 42, in authenticate
2013-08-15 18:36:57.129 4171 TRACE keystone.common.wsgi 'user_id', token_ref['token_data']['token']['user']['id'])
2013-08-15 18:36:57.129 4171 TRACE keystone.common.wsgi KeyError: 'token'
2013-08-15 18:36:57.129 4171 TRACE keystone.common.wsgi

I'm at keystone git rev 14e090154c10001550127628c2728013f15d4256

I've attached a reproducer I've been testing with (will require installing the keystoneclient patch mentioned above)

Revision history for this message
Steven Hardy (shardy) wrote :
Revision history for this message
Steven Hardy (shardy) wrote :

Working around with username/password doesn't seem to work either:

REQ: curl -i -X POST http://192.168.122.156:5000/v3/auth/tokens -H "User-Agent: python-keystoneclient" -H "Content-Type: application/json" -H "X-Auth-Token: <ADMIN TOKEN>
REQ BODY: {"auth": {"identity": {"methods": ["password"], "password": {"user": {"id": "794943ea9a57400eb0f708a524d7999f", "password": "foobar"}}, "token": {"id": "<ADMIN TOKEN>"}}, "scope": {"OS-TRUST:trust": {"id": "4d08659bbc054ea49b4464dac05c651e"}}}}

Also fails, always returns "Authorization failed. The request you have made requires authentication."

Does this mean that "methods": ["password"] is invalid for getting a token scoped to a trust?

Revision history for this message
Dolph Mathews (dolph) wrote :

Does <ADMIN TOKEN> refer to the value from keystone.conf [DEFAULT] admin_token or an real token issued through the API?

If it's the static admin_token value, then:
A) I wouldn't expect a trust to be issuable
B) It shouldn't raise a 500 - it should certainly detect the condition and raise a 401.

If it's a token issued through the API:
A) Was it issued on v2 or v3?
B) Is it a scoped to a project or domain? If so, which?

Changed in keystone:
status: New → Incomplete
Revision history for this message
Steven Hardy (shardy) wrote :

<ADMIN TOKEN> is a token obtained via cut/paste from the keystone CLI tool via "keystone token-get"

So I guess that's obtained from the v2 API:

# env | grep OS_
OS_IDENTITY_API_VERSION=2.0
OS_PASSWORD=foobar
OS_AUTH_URL=http://192.168.122.156:5000/v2.0
OS_USERNAME=admin
OS_TENANT_NAME=admin
OS_CACERT=/opt/stack/data/CA/int-ca/ca-chain.pem
OS_NO_CACHE=1

keystone token-get generated a PKI token, I generated two, one using the devstack admin credentials above (pasted into token_admin.txt), and another for the "steve" user via:

keystone --os-auth-url http://192.168.122.156:5000/v2.0 --os-username steve --os-password password token-get

So is the problem caused by it being a v2 token? The failure mode doesn't make that very clear ;)

Adam Young (ayoung)
Changed in keystone:
assignee: nobody → Adam Young (ayoung)
status: Incomplete → Confirmed
importance: Undecided → Critical
Revision history for this message
Steven Hardy (shardy) wrote :

So as discussed on IRC re token formatting issue, added some debug:

token_ref['token_data']['token']['user']['id']

should be:

token_ref['token_data']['access']['token']['user']['id']

By the looks of it

Revision history for this message
Adam Young (ayoung) wrote :

Updated the bug title, as there is nothing specific to trusts with this error case.

summary: - Authenticating with trust ID fails with 500 error
+ Authenticating v2 token against v3 api fails with error 500
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to keystone (master)

Fix proposed to branch: master
Review: https://review.openstack.org/42456

Changed in keystone:
status: Confirmed → In Progress
Dolph Mathews (dolph)
tags: added: grizzly-backport-potential
Thierry Carrez (ttx)
Changed in keystone:
milestone: none → havana-3
Dolph Mathews (dolph)
tags: removed: grizzly-backport-potential
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to keystone (master)

Reviewed: https://review.openstack.org/42456
Committed: http://github.com/openstack/keystone/commit/9bee61c57cc556994bf676fcc038e23824e08988
Submitter: Jenkins
Branch: master

commit 9bee61c57cc556994bf676fcc038e23824e08988
Author: Adam Young <email address hidden>
Date: Fri Aug 16 15:22:28 2013 -0400

    use provider to validate tokens

    Validate V2 token when passed to V3 api
    Push the validation logic to the provider
    token auth plugin works on data from v2 or v3

    Bug 1212778

    Change-Id: Ib2f77839c907d5013d33660920fa902613be4fb5

Changed in keystone:
status: In Progress → Fix Committed
Dolph Mathews (dolph)
tags: added: grizzly-backport-potential
Thierry Carrez (ttx)
Changed in keystone:
status: Fix Committed → Fix Released
Thierry Carrez (ttx)
Changed in keystone:
milestone: havana-3 → 2013.2
Alan Pevec (apevec)
tags: removed: grizzly-backport-potential
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.