RBAC research brief for the SyRF permission proposal¶
Read-only research on 3 October 2026. Recommendations below are an application of sources to SyRF, not claims that the sources prescribe SyRF's exact defaults. No framework migration or permission changes are authorized. See the action matrix for proposed actions/defaults and verified current catalogue/controller boundaries.
Primary-source findings¶
NIST separates users, roles and assigned permissions, allowing multiple roles and constrained hierarchies. The archived project explains the RBAC model and its administrative benefits; it is foundational background, not evidence of a newly issued standard. NIST RBAC project.
OWASP recommends least privilege, denial when no access rule permits an action, authorization checks on every request, safe object lookup, appropriate logging and authorization tests. It also recommends considering attributes and relationships rather than relying exclusively on roles where context matters. OWASP Authorization Cheat Sheet.
Microsoft explains that resource-dependent decisions require checking the loaded resource; controller attributes alone cannot establish ownership of a resource loaded afterwards. IAuthorizationService supports resource-based authorization. ASP.NET Core resource authorization. This guidance supports an audit of SyRF's actual authorization handlers; it is not a claim that existing handlers are absent or that the latest framework version must be adopted.
SyRF recommendations inferred from those findings¶
| SyRF fact / requirement | Concrete proposed application |
|---|---|
| Configurable project groups, project and stage grants | Treat a group as membership/bundle administration, an action capability as the permission, and project/stage as the resource scope. Reuse existing group infrastructure; no hard-coded admin/reviewer role tests. |
| Work assignments and shared-form tasks | Eligibility/claim is an additional condition, never a capability grant. A study ID must resolve to the authorized project and stage/form before reads or commands; verify nested resource IDs, not just URL project ID. |
| Shared questions/entities across stages | Include exact context/branch and source-stage policy. Do not use a weaker stage to expose candidates, bypass blinding or lifecycle approvals. Explicit task routing must retain authoritative context. |
| Owner grants administration to a group (PM2) | Extend current owner-only AssignPermissions intentionally. Recommend owner-defined allowable actions/stages/recipient groups; owner alone controls delegation envelopes and who receives delegation authority. No recursive delegation or transfer right. |
| Membership editing can change privileges | Guard joining/editing privileged groups by grant-administration authority; EditMemberships alone cannot self-escalate. Separate ordinary membership management from permission-envelope administration. |
| Ordinary admins broad ordinary grants | Make explicit configurable bundles, retain owner-reserved exceptions. Implementer chooses intuitive templates after action inventory; avoid role explosion by expressing scopes and task conditions separately. |
| Session pinning and immutable history | Pin evidence versions, not irrevocable authorization. Recheck active membership/effective grants at reads/commands and queued export delivery; revocation leaves evidence intact but prevents unauthorized new access/submission. |
| Cached grants and asynchronous operations | Propose policy revision stamp/invalidation on membership/grant changes. Recheck server-side before sensitive commit/delivery; do not rely only on stale token group claims. Exact caching/fencing protocol remains engineering. |
| Stats/gold/candidate view boundaries | Separate agreement view from candidate reads; apply stage identity blinding and permitted-stage aggregation. Summary/export/notification paths use the same disclosure policy as interactive reads. |
| Query self-review explicitly allowed | Prefer different resolver but allow authorized self-review with audit as confirmed; do not invent mandatory mutually exclusive role membership. Keep ordinary initial reconciler independence requirements separate. |
| Grant use versus grant administration | Successful Review/Reconcile never confers permission-editing authority. Audit effective authority for grant changes, actor, resource, old/new grants, approved envelope and result. |
Recommended acceptance cases: deny cross-project IDs and stale/revoked grants; enforce every command including batch and background paths; prevent recursive delegation and privileged-group self-addition; keep assignment/notification from granting access; preserve audited permitted query self-review and stage blinding. Implementation should test positive and negative cases against the approved matrix. These are recommendations, not tests run in this documentation task.
Design boundary¶
Use scoped capability checks plus existing resource/ownership/eligibility rules; no universal RBAC engine replacement, custom policy language or new persona hierarchy is needed for the MVP. Publish a complete action inventory before picking default bundles. The current owner-only catalogue is source evidence; owner-granted group delegation is the confirmed extension. Exact identifiers, ordinary admin bundle details and anti-escalation mechanics remain proposals in the matrix; bundle names are implementer discretion, not additional owner decisions.