Session token management improvement

Registered by Lin Hua Cheng

Summary:
Refactor the token management in session

Motivation:

The Token object is used by django_openstack_auth to encapsulate user and keystone related information. This is used to rebuild the django User object.

It currently stores:
1. keystone token
2. user info
3. scope
4. roles
5. service catalog.

It is currently stored in the django session to retrieved on subsequent page reload.

When a signed cookie session backend is used, the application may hit the 4k cookie limit size. One
of the reason for the growth of the cookie size is the service catalog. As more services are registered
the bigger the size of the service catalog would be.

Using default devstack setup, the service catalog take 31% of session size for V2, and 44% for V3.

The token should store the minimum information and stop storing the service catalog to be able to scale and not hit the cookie limit.

Description:

There are a number of items to be implemented
1. Token object should store the minimum data:
- keystone token
- scope
2. The rest of the information will be stored in django cache instead of storing in the session
https://docs.djangoproject.com/en/1.8/topics/cache/
3. An entry in the django cache will be created for each scoped token:
- key: token_id
- value: access_info from keystone
- expiration: token expiration
4. When horizon rebuild the user object, it will first fetch the Token object from the session.And then fetch the rest of the information from the django cache, using the token as the key.
5. If no entry from the cache can be found, it will request the access_info from keystone and store that in the cache

UX:
N/A

Outside Dependencies:
N/A

Requirements Update Required:
N/A Cache is available since Django14

Doc Impact:
Will have to document that deployer have to configure the Django Cache correctly.

Blueprint information

Status:
Complete
Approver:
David Lyle
Priority:
High
Drafter:
Lin Hua Cheng
Direction:
Approved
Assignee:
Lin Hua Cheng
Definition:
Obsolete
Series goal:
Accepted for 10.0.0-newton
Implementation:
Unknown
Milestone target:
None
Completed by
Richard Jones

Related branches

Sprints

Whiteboard

It's still unclear to me why moving this info to the django cache like this helps. Won't the django cache end up with the same issues affecting the django session?

OOTO if we computed a hash over the service catalog and kept only one copy of each service catalog variation that might save some space - is that consistent with your goals?

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.