keystonemiddleware

Unify keystone and keystonemiddleware cache

Bug #1946117 reported by George Melikov
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
keystonemiddleware
New
Undecided
Unassigned

Bug Description

Now both keystone and keystonemiddleware generate unique cache entry.

So:
- keystone issued token, wrote it to memcache with key `bd3f7bd71ac64f6f67ea84510027bdaf83b126d7`
- keystonemiddleware go to memcache and tries to find with `python -c "import hashlib; print('get tokens/'+hashlib.sha256('$token'.encode('utf-8')).hexdigest())"` command (so resulting key will be `tokens/long_different_key`
- keystonemiddleware didn't find it, goes to keystone to get token info
- keystonemiddleware write it's own cache entry

We have nearly duplicate steps here. Newly issued token usually be used in next request from user.
And some clients (for ex. openstack CLI) issues token on every run (i.e. user request).

I think it may be insecure to reuse same memcache entry, but add a step in keystone to create an entry especially for keystonemiddleware may be a way here.

Did I miss something? I've tested on Ocata but I didn't find changes in master for that.

Revision history for this message
George Melikov (gmelikov) wrote :

If I'm on the right track - I may try to implement it.

Revision history for this message
Boris Bobrov (bbobrov) wrote :

I think that it is pretty much against the idea of (micro)services that communicate to each other via a common protocol (http).

Keystone is not aware about what validates the token, and keystonemiddleware is not aware about keystone. Keystonemiddleware makes requests to an identity server. Keystonemiddleware discovers an identity server via service catalog, included in the response to service user authentication - also a step missing in your description.

I think this should not be implemented.

Revision history for this message
George Melikov (gmelikov) wrote :

> Keystonemiddleware makes requests to an identity server.

FWIW, keystonemiddleware (at least in Ocata) goes first into memcache (tested via tcpdump), so it may finish here if cache is actual and exists.

The main problem is keystone's speed. From one side it's right - microservices, communication via http, from the other side - if it's too slow - cache unification may be a viable choice.

Of course, truly right answer is to make keystone service just as fast as memcache.

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

Other bug subscribers

Remote bug watches

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