MaterializeInc
Use superuser attribute for Cloud
Motivation
See commit messages for details. Fixes https://github.com/issues/assigned?issue=MaterializeInc%7Cdatabase-issues%7C9948
Right now the behavior is the attribute / table will update when we next update the external_metadata (i.e. when we next refresh the token). We could write a catalog migration / builtin table migration for this too, but not sure how to extrapolate whether a user is a superuser from this. And practically, I believe this shouldn't make a difference given they'd need to authenticate to query mz_roles
Overall this feels kinda clunky. Talked more about it in this slack thread https://materializeinc.slack.com/archives/C08A62E0751/p1764979212773359
Tips for reviewer
Checklist
- [ ] This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
- [ ] This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
- [ ] If this PR evolves an existing
$T ⇔ Proto$Tmapping (possibly in a backwards-incompatible way), then it is tagged with aT-protolabel. - [ ] If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
- [ ] If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.
I got random-assigned to this PR as a reviewer, but unfortunately I don't really know how authentication/Frontegg works, nor have I ever looked into role stuff. I could dig into this, but maybe there is someone (besides you) who already knows this stuff better than me? If not, then I'll dive into it.
Also, maybe a question for @ohbadiah, does GitHub's random reviewer assignments from @MaterializeInc/adapter make sense nowadays? For example, for my last ~10 PRs it was clear that definitely either Jan or Aljoscha should review them, because they had all the context on the frontend peek sequencing, so when Jun got random-assigned I always just overruled it manually. Maybe this random reviewer assignment system plus the recent team shifts are somehow contributing to the phenomenon mentioned in the last R&D Sync that PR reviews gotten less prompt recently? Maybe when somebody gets random-assigned they feel less responsible for the review than when somebody explicitly, personally asks them (sometimes after a discussion of who would be the best reviewer). (Another example is https://github.com/MaterializeInc/materialize/pull/34379, which either Petros or me should review probably, rather than the randomly-assigned Aljoscha.) Edit: Started a Slack discussion.
Figured @jubrad has the best context and might be more opinionated on the approach here
Edit: If you don't have the spare cycles, Dov mentioned he could review it too
We could write a catalog migration / builtin table migration for this too, but not sure how to extrapolate whether a user is a superuser from this. And practically, I believe this shouldn't make a difference given they'd need to authenticate to query mz_roles
Yeah, I'm not sure we can do a catalog migration, unless we've durably recorded the roles metadata somewhere. If we haven't we may still want this to be nullable -> if we don't know and a user hasn't logged in the value is null.
I think there's a good way to do this and a bad way to do this.
The good way: Map the user role in FE to a role in the users IDP then automate sink via SCIM, we can still check at token refresh, or we can poll FE more frequently, or ideally stream user membership changes. The more real time you want this the more complicated it its. The bad way: We note that this is just a view of the roles based on the last login/token refresh and may be stale. Clearly then we only refresh the role on token refresh.
We may want @jasonhernandez to weigh in here as well.
Putting as draft to discuss tradeoffs and solutions in https://materializeinc.slack.com/archives/C08A62E0751/p1764979212773359