New token always returned

This is a change in behavior from essex-2... So, please confirm if this is intended or indeed a bug...

This is definitely not the intended behavior.

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

I wrote a pair of tests for the following scenarios:

    1) authenticating for an unscoped token twice
    2) authenticating for a scoped token twice

Both tests already pass in master - marking this bug as invalid for now, unless you have a more specific scenario? If so, a failing test would be helpful! Thanks, Liem!

I'm confused what a token is if a new token shouldn't be generated each time you authenticate?

Reviewed: https://review.openstack.org/3424
Committed: http://github.com/openstack/keystone/commit/2efd3117bd8103f16bf561873deaa5210db257cb
Submitter: Jenkins
Branch: master

commit 2efd3117bd8103f16bf561873deaa5210db257cb
Author: Dolph Mathews <email address hidden>
Date: Wed Jan 25 13:53:23 2012 -0600

    Test coverage for issue described in bug 919335

    Change-Id: I5608968ba287e732216da9c883a32a16b2b15523

Jesse, is there a business case to support one behavior over the other?

I'm thinking of the security model.

What does a token represent? In some (all?) token systems, a token represents an authentication session. So if the same token is returned for every auth request (eg, every session) then you don't have the potential to revoke for a given context.

The token represents access granted for a specific time period. Think of it as a 'handle' to the set of data describing the access granted. It is not associated with a session. Returning the same token for the same credentials has significant scalability benefits, and is perfectly sound if you're not associating the concept of a token with a session.

Where is the need for multiple tokens coming from? Can you describe the use case more? There's nothing in the spec forcing the current behaviour; just our experience at scale. For low volume deployments, we could enable a config that returns new tokens for each Auth request.

On Jan 26, 2012, at 2:32 PM, "anotherjesse" <email address hidden> wrote:

> I'm thinking of the security model.
>
> What does a token represent? In some (all?) token systems, a token
> represents an authentication session. So if the same token is returned
> for every auth request (eg, every session) then you don't have the
> potential to revoke for a given context.
>
> --
> You received this bug notification because you are a member of Keystone
> Bugs, which is subscribed to Keystone.
> https://bugs.launchpad.net/bugs/919335
>
> Title:
> New token always returned
>
> Status in OpenStack Identity (Keystone):
> Fix Committed
>
> Bug description:
> Branch: Master
>
> Doing a POST /tokens for joeuser (user
> 061110baf07c4fa6aa3acdfe7ab4e33c (tenant:
> c8c8e3ea89834869b5060bbc6dd02da4)) generates a new token every time
> (even when the old token hasn't expired). It appears we cannot find
> the token from the DB (sqlalchemy)...
>
> 2012-01-20 10:07:49 DEBUG [keystone.frontends.d5_compat] Entering D5AuthProtocol.__call__
> 2012-01-20 10:07:49 DEBUG [routes.middleware] Matched POST /tokens
> 2012-01-20 10:07:49 DEBUG [routes.middleware] Route path: '/tokens', defaults: {'action': u'authenticate', 'controller': <keystone.controllers.token.TokenController object at 0x2bcf7d0>}
> 2012-01-20 10:07:49 DEBUG [routes.middleware] Match dict: {'action': u'authenticate', 'controller': <keystone.controllers.token.TokenController object at 0x2bcf7d0>}
> 2012-01-20 10:07:49 DEBUG [keystone.logic.service] Authenticating with passwordCredentials
> 2012-01-20 10:07:49 DEBUG [keystone.logic.service] Authenticating user 061110baf07c4fa6aa3acdfe7ab4e33c (tenant: c8c8e3ea89834869b5060bbc6dd02da4)
> 2012-01-20 10:07:49 DEBUG [keystone.logic.service] Token was not found or expired. Creating a new token for the user
> 2012-01-20 10:07:49 DEBUG [keystone.logic.service] User 061110baf07c4fa6aa3acdfe7ab4e33c failed check - did not have role 2
> 2012-01-20 10:07:49 DEBUG [keystone.logic.service] User 061110baf07c4fa6aa3acdfe7ab4e33c failed check - did not have role 1
> 2012-01-20 10:07:49 DEBUG [eventlet.wsgi.server] 127.0.0.1 - - [20/Jan/2012 10:07:49] "POST /v2.0/tokens HTTP/1.1" 200 1858 0.146559
> 2012-01-20 10:07:55 WARNING [keystone.frontends.normalizer] Falling back to `webob` v1.1 and older support. Check your version of webob
> 2012-01-20 10:07:55 DEBUG [keystone.frontends.normalizer] */* header could not be matched
> 2012-01-20 10:07:55 DEBUG [keystone.frontends.legacy_tok...

Scale has had us opt for returning the same token. Tokens should not be used as a browser session identifier.

On Jan 26, 2012, at 10:37 AM, "Dolph Mathews" <email address hidden> wrote:

> Jesse, is there a business case to support one behavior over the other?
>
> --
> You received this bug notification because you are a member of Keystone
> Bugs, which is subscribed to Keystone.
> https://bugs.launchpad.net/bugs/919335
>
> Title:
> New token always returned
>
> Status in OpenStack Identity (Keystone):
> Fix Committed
>
> Bug description:
> Branch: Master
>
> Doing a POST /tokens for joeuser (user
> 061110baf07c4fa6aa3acdfe7ab4e33c (tenant:
> c8c8e3ea89834869b5060bbc6dd02da4)) generates a new token every time
> (even when the old token hasn't expired). It appears we cannot find
> the token from the DB (sqlalchemy)...
>
> 2012-01-20 10:07:49 DEBUG [keystone.frontends.d5_compat] Entering D5AuthProtocol.__call__
> 2012-01-20 10:07:49 DEBUG [routes.middleware] Matched POST /tokens
> 2012-01-20 10:07:49 DEBUG [routes.middleware] Route path: '/tokens', defaults: {'action': u'authenticate', 'controller': <keystone.controllers.token.TokenController object at 0x2bcf7d0>}
> 2012-01-20 10:07:49 DEBUG [routes.middleware] Match dict: {'action': u'authenticate', 'controller': <keystone.controllers.token.TokenController object at 0x2bcf7d0>}
> 2012-01-20 10:07:49 DEBUG [keystone.logic.service] Authenticating with passwordCredentials
> 2012-01-20 10:07:49 DEBUG [keystone.logic.service] Authenticating user 061110baf07c4fa6aa3acdfe7ab4e33c (tenant: c8c8e3ea89834869b5060bbc6dd02da4)
> 2012-01-20 10:07:49 DEBUG [keystone.logic.service] Token was not found or expired. Creating a new token for the user
> 2012-01-20 10:07:49 DEBUG [keystone.logic.service] User 061110baf07c4fa6aa3acdfe7ab4e33c failed check - did not have role 2
> 2012-01-20 10:07:49 DEBUG [keystone.logic.service] User 061110baf07c4fa6aa3acdfe7ab4e33c failed check - did not have role 1
> 2012-01-20 10:07:49 DEBUG [eventlet.wsgi.server] 127.0.0.1 - - [20/Jan/2012 10:07:49] "POST /v2.0/tokens HTTP/1.1" 200 1858 0.146559
> 2012-01-20 10:07:55 WARNING [keystone.frontends.normalizer] Falling back to `webob` v1.1 and older support. Check your version of webob
> 2012-01-20 10:07:55 DEBUG [keystone.frontends.normalizer] */* header could not be matched
> 2012-01-20 10:07:55 DEBUG [keystone.frontends.legacy_token_auth] Entering AuthProtocol.__call__
> 2012-01-20 10:07:55 DEBUG [keystone.frontends.legacy_token_auth] Not a v1.0/v1.1 call, so passing downstream
> 2012-01-20 10:07:55 DEBUG [keystone.frontends.d5_compat] Entering D5AuthProtocol.__call__
> 2012-01-20 10:07:55 DEBUG [routes.middleware] Matched POST /tokens
> 2012-01-20 10:07:55 DEBUG [routes.middleware] Route path: '/tokens', defaults: {'action': u'authenticate', 'controller': <keystone.controllers.token.TokenController object at 0x2bcf7d0>}
> 2012-01-20 10:07:55 DEBUG [routes.middleware] Match dict: {'action': u'authenticate', 'controller': <keystone.controllers.token.TokenController object at 0x2bcf7d0>}
> 2012-01-20 10:07:55 DEBUG [keystone.logic.ser...

Recommend this topic be introduced as a blueprint if there is still interest in changing/discussing this behavior.