Keystone Should re-use non-expired tokens, instead of generating new tokens.

Bug #1215627 reported by Sean McCully
24
This bug affects 4 people
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Invalid
Wishlist
yong sheng gong

Bug Description

Keystone should re-use user non-expired tokens on create requests.

If user requests a new token, then Keystone should authenticate and instead of generating a new token, reuse an existing token.

Revision history for this message
ZhiQiang Fan (aji-zqfan) wrote :

Why? If the user want to get a new token, maybe he think the old one is not safe any more. This kind of optimize actually presume user's environment and may confuse the end user.

Revision history for this message
Sean McCully (sean-mccully) wrote :

Creating a new token doesn't expire any current tokens ... ?
Workflow as described should be.
-- Expire/Delete Current Token
-- Request New Token

Revision history for this message
Sean McCully (sean-mccully) wrote :

As for why, current openstack services request additional tokens fairly regularly. This quickly expands the token table.
Solution, reuse non-expired tokens.

Revision history for this message
yong sheng gong (gongysh) wrote :

I think it is good to have this fixed.

Changed in keystone:
status: New → Confirmed
assignee: nobody → yong sheng gong (gongysh)
Revision history for this message
yong sheng gong (gongysh) wrote :
Download full text (3.3 KiB)

<henrynash> gongysh:hi
<gongysh> henrynash: what is your opinion of the bug https://bugs.launchpad.net/keystone/+bug/1215627
* morganfainberg is now known as morganfainberg|a
<uvirtbot> Launchpad bug 1215627 in keystone "Keystone Should re-use non-expired tokens, instead of generating new tokens." [Undecided,Confirmed]
<gongysh> it is nice if we can have it fixed since the nova is creating too much token during running.
* nshaikh (nshaikh@nat/redhat/x-qhxcxectchlfnsqc) has left #openstack-dev ("Quit")
* mrunge (~mrunge@fedora/mrunge) has joined #openstack-dev
* dstufft (~dstufft@django/committer/dstufft) has joined #openstack-dev
<gongysh> the nova will use the neutron client to flush the all instances IP information periodically, which will generate many tokens.
<gongysh> flush -> refresh, or get or query.
<henrynash> gongysh; I agree that the number of tokens is a probelm
* zodiak has quit (Ping timeout: 256 seconds)
* MaxV (~MaxV@90.24.240.225) has joined #openstack-dev
<gongysh> henrynash: then what is your advised solution? do u agree to the solution in the bug 1215627?
<uvirtbot> Launchpad bug 1215627 in keystone "Keystone Should re-use non-expired tokens, instead of generating new tokens." [Undecided,Confirmed] https://launchpad.net/bugs/1215627
<henrynash> gongysh: sp is the idea that we re-use the token ID with a new expiry time?
<henrynash> gongysh: (sorry slow to respond since I am on a call)
* mmagr (mmagr@nat/redhat/x-wrqxejdxwkdikfzr) has joined #openstack-dev
* dina_belova (~dina_belo@95-29-221-112.broadband.corbina.ru) has joined #openstack-dev
* vartom4 has quit (Ping timeout: 256 seconds)
<gongysh> henrynash: Yes, we can refresh the expiry time whenever the token is reused.
<gongysh> henrynash: or we can just return the token with old expiry time.
* SergeyLukjanov (~Frostman@95-29-221-112.broadband.corbina.ru) has joined #openstack-dev
<henrynash> gongysh: so I want to be clear of the user case: are we trying to optimise for when a user asks for a new token lists of times when they have a perfectly good one already, or when their token is expiring?
<gongysh> henrynash: we can add one configuration option to allow use the active token, such as reuse_valid_token = False
* dina_belova has quit (Read error: Operation timed out)
<jamielennox> gongysh: what is the scenario here? why is it filed as a keystone bug?
<jamielennox> it sounds like it is an issue with the way that services consume keystone tokens
<gongysh> keystone will always return a new token if user calls the authentication API even if the information given by user are the same.
* Mandell (~<email address hidden>) has joined #openstack-dev
<jamielennox> gongysh: i would consider that to be the expected behaviour
<henrynash> gongysh: and would we re-use the token even the scope/details of that token were different to the last one, or only if it has been requested for the same scope
<henrynash> gongysh: worried about auditing etc.
<gongysh> henrynash: I am expecting reuse token if the scope is the same.
* morganfainberg|a is now known as morganfainberg
* marios (~m@93-23-6.netrun.cytanet.com.cy) has joined #openstack-dev
<henrynash> gongysh: ok, s...

Read more...

Revision history for this message
Sean McCully (sean-mccully) wrote :

That sounds accurate,

* Re-publish/Respond with same token for requests that request a new token with same params.

One additional note, is
* I do not think you would want to refresh the expiry time (since user configuration specifies what that should be), tokens should be "handed" out with same expiry time, until it expires.

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

Normal users may not be able to revoke their own tokens... on v2.0, it's simply not part of the public API. On v3, it's up to policy.json and I believe the current default would deny this use case.

Another use case that conflicts with this behavior- what if my token is about to expire and I'd like to create a fresh one before performing a long-running operation?

Changed in keystone:
importance: Undecided → Wishlist
description: updated
Revision history for this message
Dolph Mathews (dolph) wrote :

Revised the description to exclude "at least when using a sql driver backend" -- it would be unacceptable for a single driver to behave in such a radically different fashion from the others.

Revision history for this message
Sean McCully (sean-mccully) wrote :

To the first case, I agree that would be problematic I think the solution here is for tokens with long expiration times and based on configuration to provide a fresh token within a reasonable time-frame before the current token expires.

As for the behaviour around specific driver implementations, I would only say that it may not make sense with some driver back-ends to behave this way. Though I have no strong objections one way or the other, that it should be decided that all back-ends "MUST" behave in the same manner.

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

So, you're suggesting that as a user with a token about to expire, I have no way of knowing if I'll get back a new token or the same token I already have? (because I have no way of knowing how the service is configured)

Revision history for this message
Sean McCully (sean-mccully) wrote :

As a user, you are given a token by the system that you can authenticate, with a timestamp that tells you when it expires. Then it is up to you as the user to use that token till it expires. If you continue to use that token beyond the expiration timestamps then its a user error.

I would suggest that it might be user friendly to generate a new token during a create token requests that would have otherwise returned the current token when the current token is close to expiry.

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

You are describing an unpredictable API. That is NOT user error.

Revision history for this message
Sean McCully (sean-mccully) wrote :

unpredictable, I fail to see what is unpredictable?

Revision history for this message
Sean McCully (sean-mccully) wrote :

Allowing an operator to decide how to close to token expiration a new token should be handed out.

I would think allowing an API to be configured and behave as dictated by the entity running the API, would be more of a service model then unpredictable or dictating that all instances of said software behave the same.

If a user requests a token and that token has an expiration date, and user tries to use token beyond expiration and expects it to work. That would be the definition of an USER ERROR.

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

See comments #7 and #10

> about to expire

Perhaps this bit was unclear and would have been better described as "nearing expiration" or "not yet expired."

Revision history for this message
Sean McCully (sean-mccully) wrote :

Now I am a bit confused,

Is there a still question about behaviour, here?

Revision history for this message
Ravi Chunduru (ravivsn) wrote :

This is really effecting keystone performance in large scale deployments. I would definitely agree for this fix. Here are additional comments

1) Should check possibility of clients specifying scope of the token wrt duration in its request to keystone. Either specifying as short, long lived tokens or specific duration must be considered.
2) Keystone server should not re-use tokens that has time duration less than configured threshold duration and also look into the request whether it requests short or long lived tokens.

Revision history for this message
yong sheng gong (gongysh) wrote :

https://github.com/openstack/python-keystoneclient/commit/d734821c99aade7cd4285a5fd51736c475707dcd
it seems the client has done with it via keyring.

keystone --help:
...
  --os-key <key> Defaults to env[OS_KEY]
  --os-cache Use the auth token cache. Defaults to env[OS_CACHE]
  --force-new-token If the keyring is available and in use, token will
                        always be stored and fetched from the keyring until
                        the token has expired. Use this option to request a
                        new token and replace the existing one in the keyring.
  --stale-duration <seconds>
                        Stale duration (in seconds) used to determine whether
                        a token has expired when retrieving it from keyring.
                        This is useful in mitigating process or network
                        delays. Default is 30 seconds.

Revision history for this message
yong sheng gong (gongysh) wrote :

however, I think we need to do it on the server side.

Revision history for this message
Sean McCully (sean-mccully) wrote :

I really dont think allowing for clients to specify a token duration to the server fixes the problem at all. Unless short token durations were in actuality long time spans.

Revision history for this message
Sean McCully (sean-mccully) wrote :

Here is another view point, by allowing clients to specify a short lived token. What you actually allowing the client to accomplish in one task is the otherwise two step procedure of requesting a token, and subsequently expiring a token.

I can't think of an overwhelming reason, why this process needs to be simplified at this point.

Revision history for this message
Arun Kant (arukant) wrote :

I will also like to get this fixed. And from above discussion, I cannot see what is the final approach recommended for this issue.

Is the plan to use same token id with updated expiry if there is a valid active token with matching scope exists for that user/client? That will work for most part. One possible concern with this can be that a given token id can be re-used for multiples of token expiry duration. May be we can limit this so that there is a predictable behavior around this.

I mean..for successive authentication request with same credentials and scope, return existing active token if there and extend the expiry (= current_time + expiry_duration). If authentication request happens after one complete expiration (token_create_time + expiry_duration < current_time ), issue a new token id otherwise use current active token. This way, the proliferation of token ids can be limited and a specific token_id will be valid for maximum of 2 configured expiry duration.

I like the configurable approach so that it can be turned on based on operator preferences.

Revision history for this message
David Stanek (dstanek) wrote :

Is there any architectural information about how tokens should be used? I found docs for the APIs, but I'm looking more for usescases and best practices about using/handling tokens.

It may be a little late now, but I would have loved to see tokens not be stored at all. Instead just the grant and an optional expiration on the grant. Grants can then be used to create new tokens. If a grant is revoked all associated tokens are revoked. tokens would have their own expiration date that is likely shorted than that of the grant (except in the case where a grant will expire). This is similar in concept (I believe) to some large scale OAuth deployments.

Revision history for this message
Morgan Fainberg (mdrnstm) wrote :

This seems like the wrong approach. If a token is meant to be re-used the client (be it the python-*client OS provides or something else) should use it. New authentication should result in a new token (regardless of storage of said token on the backend). Re-issuance of the same token is a bad idea and breaks with the general direction we are trying to go with having truly ephemeral tokens.

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

Ooh, I meant to provide an update here. This whole conversation is moot if keystone doesn't need to persist tokens at all (and therefore wouldn't have any means to "re-issue" them). That's what we're driving towards in icehouse:

  https://blueprints.launchpad.net/keystone/+spec/ephemeral-pki-tokens

Revision history for this message
Morgan Fainberg (mdrnstm) wrote :

As Dolph pointed out this is not the direction we are going with tokens. This issue will be handled by ephemeral tokens.

Changed in keystone:
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related blueprints