OPA roles are only resolved at login, so role changes and offboarding don't reach live sessions

Start by locating OpaSupersetSecurityManager and its existing OPA client and TTLCache wiring. Trace where role resolution currently occurs during login, then determine how request-time checks should handle changed or empty roles within the TTL. Done means live sessions reflect OPA role changes or offboarding within the configured delay, with coverage for both cases.

Use case

When configuring OPA role mapping for Apache Superset, role changes in OPA should take effect on Superset sessions that are already logged in within a predictable amount of time.
Removing someone's roles (or totally offboarding them) should actually revokes access without having to wait until they login again (which they cannot even do, if they were offboarded).

The problem

OpaSupersetSecurityManager only resolves roles on login. After that Superset uses the Flask-Login cookie and never talks to OPA again. So changing or removing a user's roles in OPA does nothing to a live session, this session will keep the roles it had at the last login.
This is especially critical, since sessions don't really have a maximum life time, but can in theory be kept alive indefinitely by not letting them become idle.

So effectively a user that is disabled in Keycloak could keep using a logged in Superset session with their last credentials forever.
Blast radius obviously depends on many things like if impersonation is used for Trino etc., but this is far from ideal.

Work-around

Partial only: shorten PERMANENT_SESSION_LIFETIME, or rotate SECRET_KEY to kill all sessions at once.
One is not really helpful, the other is overkill.

Possible solutions

Not a complete list, just what occured to me (and Claude) so far:

• Re-check OPA on requests and log the user out (or resync roles) when their roles come back empty, gated by a TTL so we only re-check once the last result is older than X seconds
• Push offboarding from Keycloak (event listener/webhook). Rejected as primary fix, needs control over Keycloak, which we usually don't have.
• Generic before_request guard keyed on ab_user.active. Needs an external process to flip active and ignores OPA, our actual source of truth.

Recommendation

Personally I think option 1 makes most sense. We already wire in a custom security manager that we control and which is at the ideal place to control this. It already holds an OPA client and a TTLCache, which is a lot of the plumbing we need.

At the moment it syncs roles only on login, but we could change that to run on every request, and then restrict it to only actually do something every x seconds/minutes... This would mean that we can effectively control the maximum delay until changes in Keycloak are pushed down to Superset - instead of relying on user behavior (login) for this.