Implement Tokens in memcache

Bug #843127 reported by klmitch
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Fix Released
High
Unassigned

Bug Description

To separate tokens from core logic and make it part of token auth.
But make this a reuseable library so we can reuse it for other token-like protocols (like OAUTH).

And add memcache as a supported backend for Tokens.

Tags: feature
Revision history for this message
klmitch (q-noreply) wrote :

Memcache is usually used as a cache store.It stores information for a while and then discards them.Its capable of storing values as key value pairs.I am not sure how we plan to use memcache.I dont think it would fit our usage cases.

Revision history for this message
klmitch (q-noreply) wrote :

The risks for me are
We don't have control over memcache eviction policies.

Reference: http://code.google.com/appengine/docs/python/memcache/overview.html

How Cached Data Expires on memcache
By default, values stored in memcache are retained as long as possible. Values may be evicted from the cache when a new value is added to the cache if the cache is low on memory. When values are evicted due to memory pressure, the least recently used values are evicted first.
The app can provide an expiration time when a value is stored, as either a number of seconds relative to when the value is added, or as an absolute Unix epoch time in the future (a number of seconds from midnight January 1, 1970). The value will be evicted no later than this time, though it may be evicted for other reasons.
Under rare circumstances, values may also disappear from the cache prior to expiration for reasons other than memory pressure. While memcache is resilient to server failures, memcache values are not saved to disk, so a service failure may cause values to become unavailable.

Since you have outlined that we are fine with the eviction as of now this is how I plan to implement.

A token entity is a made of id, user_id,tenant_id and expires.Some of the valid token use cases are
1. Validate token call (User passes a token and an optional tenant_id and we need to validate token existence and return specific user information and token information.
2. Get Token for the tenant/user combo when an authenticate call is made.

Memcache uses a key/value mapping.It could return values based on a key.However for our token scenario there are multiple cases of retrieval.
1. Retrieve token info based on actual token value and a tenant combo.(if tenant exists else treat tenant as null)
2. Get token for the tenant_id/user_id combo.
Value mapped would be the complete Token entity made of( id, user_id,tenant_id and expires) for both the cases.

This implies that we got to map the same values with multiple keys,The retrieval scenarios would work.We could set the cache time to be same as token expiry time and allowing cache to automatically expire.

During revocation i shall revoke token from each of the retrieval cases.

Also we have already done enough backend work that allows us to separate entities to different back ends.Backend model what we have right now is sufficient to support the separation.

Also we got to have memcache run in a distributed mode to allow things to work in a multi node set up.

Revision history for this message
klmitch (q-noreply) wrote :

I have done the initial implementation and might commit it.
After discussing with Ziad have decided that we also need to build a caching layer or check and find whether there is a second level caching layer that could be used with sqlalchemy.Just caching the tokens might not be sufficient as we make checks to determine whether the tenant and user are enabled.

Revision history for this message
klmitch (q-noreply) wrote :

Have committed the initial code.Entire tokens are cached and maintained on memcached just like any other back end.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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