RBAC model

Ministrium uses RBAC (Role-Based Access Control). Instead of assigning individual permissions to each user, permissions are grouped into roles, and roles are assigned to users.

The three entities

User  ──►  Assignment  ──►  Role  ──►  Permission

• Permission: an atomic action (donations.read, members.write, kiosk.operate).
• Role: a named bundle of permissions (org_admin, leader, finance).
• Assignment: the join of a user, a role, and a scope (whole org or specific campus).

Why RBAC and not loose permissions?

• Auditable: if you revoke the finance role, you know exactly which permissions the person lost.
• Rotatable: when someone leaves a role, you just change their role.
• Reproducible: two volunteers with the same role have exactly the same access. No surprises.

How a request is evaluated

1. The user attempts an action (e.g. view donations of the North campus).
2. Ministrium identifies the required permission (donations.read).
3. Verifies the user has a role that includes that permission.
4. Verifies the role’s scope covers the North campus.
5. If both conditions hold, the action proceeds. Otherwise 403.

// Example of a scoped user
{
  "user_id": "u_123",
  "assignments": [
    { "role": "campus_admin", "scope": { "campus_id": "c_north" } },
    { "role": "leader", "scope": { "campus_id": "c_downtown", "group_ids": ["g_42"] } }
  ]
}

This user is admin of the North campus and leader of a single group at Downtown. They can see all attendance in North but only their group’s attendance at Downtown.