Conversation
| define member: [user] | ||
| define serviceaccount: [user] | ||
|
|
||
| # admin-only operations (czars cannot do these): |
There was a problem hiding this comment.
note, i developed the models and then asked an agent to check if this fits. It does, with our current mostly role-based access control in coact.
I also asked to generate these comments on what this entails for admin/czar/principal/leader, so if any of these seem off, we can double check. I asked agent to triple check a few times :)
|
Looks good and is consistent with the current data model as far as I can tell. |
There was a problem hiding this comment.
Pull request overview
Adds a minimal OpenFGA authorization model for “coact” together with inline relationship tuples and model checks to validate expected permission behavior (system admin, facility czar, repo roles, and isolation).
Changes:
- Introduce a pared-down OpenFGA model (system → facility → repo) with
admin,can_manage, andcan_viewrelations. - Add example tuples to exercise inheritance and facility/repo isolation.
- Add OpenFGA model tests covering common role/permission scenarios.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
You can also share your feedback on Copilot code review. Take the survey.
| define can_view: member or can_manage | ||
|
|
||
| type repo |
There was a problem hiding this comment.
There’s trailing whitespace on an otherwise blank line here (line between define can_view: member or can_manage and type repo). This can cause noisy diffs and may trip whitespace/formatting checks; consider removing the spaces so the line is truly empty.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
This adds an openfga model for coact. I took the one that already exists in
schema/model.fga, and reduced it down to something minimal. I believe this encompasses all the coact things as they are without adding a lot of tuple management overhead.Here we would just be replacing calls in
auth.pyinstead of replacing a lot of the logic authz logic.We can discuss this model, along with how this fits into the rest of the authz ecosystem here (including slurm, posix groups, features, etc.). Would be good to understand how we would sync state with the other sources of truth like Grouper/IAM.
For AmSC - I read in some drive document that was created a while ago that we would be mapping amsc project IDs to particular repos. I am not sure if this is still the plan. If it is, this would be a relatively simple addition to this model and we could be off to the races with the token exchange stuff… obv more complicated than that :D