Ability to track and revoke sessions

[Fryguy]

As an admin, I'd like an endpoint to be able to revoke all sessions for a particular user
As an user, I'd like an endpoint to be able to revoke all of my sessions
As an admin or user, I'd like to specify one or more or all types of sessions when I make the revoke call

---

Observations

The UI maintains its session via a Rack session. The way this works is that when a user makes a request, Rack will assign that request a session id, and the response will include that session id as a cookie. Then subsequent requests are made with that cookie, and the session is continued for that user. Since sessions are distributed by Rack, these are not done in a user context, and therefore sessions are not directly associated with a user.

The backing store for a session is based on the Settings.server.session_store value and interpreted in an initializer here. In all cases, we use the underlying Rails session stores.

• :active_record_store ultimately ends up using the Session model
• :memory_store is in-memory
• :mem_cache_store ultimately uses Rack::Session::Dalli from the dalli gem.

The API maintains tokens in a bespoke manner. The TokenManager is used for token generation, and generated values are stored in the TokenStore. The TokenStore looks at Settings.server.session_store, but doesn't use the same Rack session code, instead of doing it itself.

---

Proposal

• Find a way to store the user id as part of the session for indexed lookup. The idea here is to be able to look up all current sessions by the user's id:
  • :active_record_store - this would mean adding a sessions.user_id column. (Sub Issue: Provide a mechanism for storing a user id to a Rack session #20462 Link user to session ids to enable looking up the session ids of every session a user owns #20476 , PRs: Link user to the sessions create to enable lookup of all sessions by user #20477 Add User.revoke_sessions #20601 Add relationship from sessions to users manageiq-schema#503 )
    Update: We can use the sessions table to link users to session ids regardless of the configured session store
  • :memory_store - this would mean adding a second memory-based index of the user's id => session list or reusing the existing lookup, but with a prefix. (Provide a mechanism for storing a user id to a Rack session for active_record_store. #20463)
  • :mem_cache_store - this would mean storing a second entry mapping the user id to a list of sessions (which may mean we need an atomic update - CAS). (Provide a mechanism for storing a user id to a Rack session for memory_store #20464)
• Methods for terminating user sessions. (Sub Issue: Methods for terminating user sessions #20548 , PR: Add ManageIQ::Session, with adapters and .revoke functionality #20549 )
• Introduce a revoke backend command and /api/revoke endpoint (Add endpoint to revoke user sessions manageiq-api#884). A user should be able to revoke their own sessions. A super-admin can revoke anybody's sessions. (Add action "revoke sessions" to users_controllers manageiq-api#900, Add revoke_session to miq_product_features.yml #20633)
• In a multi-appliance setup (with memcache), we will need to broadcast a revoke to all appliances, since each will have their own memcache. (Sub Issue: Need multi-appliance revoke user support  #20465 , PR: Add User.revoke_sessions #20601)
• Create Session Store abstraction for all the types (Add ManageIQ::Session, with adapters and .revoke functionality #20549)

[kbrock]

Idea for item 4

Is it possible to have a single memcachd instance for multiple instances like we do for the database? This is the original intent of memcached

@himdel Do we store have too much data in the session for a single (remote) database to work?

[himdel]

Do we store have too much data in the session for a single (remote) database to work?

The old forms do still use the session for all the form data. It should not longer store any instances, but a list of all eligible somethings.id+label to populate a selectpicker would still be stored in the session.

So, yeah, I think it should work (but it may not be much faster than sql for data-heavy forms, until those get converted).

[himdel]

For the API, remove a majority of the custom TokenManager / TokenStore implementation and use the Rails conventions to treat a session like a token, leveraging Rack sessions.

So, SUI would use cookies?
Does this mean relying on ui-classic to log in, or making SUI into a rails engine to have a server part to get the cookie and csrf from? Or will the API implement a login screen?

[Fryguy]

While the rack session defaults to cookies, I think we may be able to change it to use any header (a cookie is just a header after all). If it's a response header then it's really no different than any other token returned in the header.

Or, yeah, maybe SUI should just use cookies...might be a lot easier and consistent?

[himdel]

I think we may be able to change it to use any header (a cookie is just a header after all).

Ah, good point, cool :)

Or, yeah, maybe SUI should just use cookies...might be a lot easier and consistent?

Maybe, I'm not opposed to it, but a login cookie should be http(s)-only, which means we need to be able to do a login action that results in the server returning the cookie and either html, or a redirect to a html endpoint (not json).

So we would need to reuse the ui-classic login screen, or add one to the API.

[Fryguy]

Done