[albertodonato]

The JWT request loader now gets the user's database role from the new stacklet:rls_access claim, following the claim table in the ENG-9107 design (step 5):

stacklet:rls_access	Result
absent (token minted before the claim)	fall back to stacklet:db_role
unrestricted	db_role = None: queries run as the data source user, unfiltered
no_visibility	401
matches [a-z0-9_]+_[0-9a-f]{6}	db_role = "sso_" + stem
anything else (empty, wrong type, trailing newline…)	401

• When stacklet:rls_access is present it overrides stacklet:db_role.
• The fallback path now also returns 401 for stacklet:db_role = no_visibility. Before, such a user was let in, but every query failed because that role can't log in.
• The role is worked out before the user is looked up or created, so a denied token never creates or updates a Redash user.
• Role names come out the same as today, so stored users.db_role values, cached query results and the query_results policy are unaffected.

The ENG-9107 design calls this claim stacklet:rls_stem; it is renamed to stacklet:rls_access here because its value is either a stem or one of the reserved values unrestricted and no_visibility. The platform and Superset changes need to use the same name.

This can ship before the platform starts minting stacklet:rls_access: until then every token takes the fallback path.

How is this tested?

• Unit tests (pytest, jest)

New tests in tests/test_authentication.py::TestJWTAuthentication, one per row of the table, plus: the new claim overrides stacklet:db_role, unrestricted clears a previously stored role, and the fallback denies limited_visibility and no_visibility. All 48 tests in tests/test_authentication.py pass against the CI compose stack.

Related Tickets & Documents

• ENG-9644
• Epic: ENG-9107

🤖 Generated with Claude Code