As a beginner programmer designing a system with users, admins, organizations, roles, and audit forms, you're facing a foundational architectural decision: which authorization model best fits your requirements? Let's demystify the three primary models and evaluate them against your described structure.

Your System Components:

  • Users: Individuals accessing the system
  • Admins: Privileged users with broader permissions
  • Organizations: Groups where users belong
  • Roles: Permissions containers assigned to users within organizations
  • Audit Forms: Resources requiring read/write permissions

Authorization Model Breakdown:

  1. Role-Based Access Control (RBAC)
if (user.hasRole('OrgAdmin') && resource.organization == user.organization) {
    grantWriteAccess();
}

Pros: Simple implementation, ideal for organizational hierarchies. Assign permissions to roles (e.g., "Auditor"), then assign roles to users. Perfect for your role-to-organization relationship.
Cons: Struggles with granular resource-specific rules (e.g., "Only managers can edit their department's audit forms").

  1. Relationship-Based Access Control (ReBAC)

    "ReBAC evaluates connections between entities – like whether a user belongs to the organization that owns the audit form."
    Pros: Excels at your organizational hierarchy and user-role-org relationships. Permissions derive from relationships (e.g., "Users can edit audit forms if they belong to the form's organization and have the Auditor role").
    Cons: Higher complexity; requires modeling relationships as graphs.

  2. Attribute-Based Access Control (ABAC)

Policy: Permit if 
  user.department == resource.department && 
  user.role == 'Auditor' && 
  resource.type == 'audit_form'

Pros: Highly granular. Uses attributes (user role, resource type, organization ID, time of day) for dynamic decisions.
Cons: Significant complexity overhead; requires policy engines like Cedar or OPA.

Recommendation for Your Use Case:

Start with RBAC for its simplicity and direct mapping to your described structure:
1. Define roles per organization (e.g., OrgAdmin, Auditor, Viewer)
2. Assign resource permissions to roles (e.g., Auditor can read/write audit forms)
3. Assign users to roles within their organization

When to evolve: If you later need:
- Permission variations within roles (e.g., "Auditors can only edit their own forms")
- Dynamic rules based on form status or user attributes

...consider hybrid approaches:
- RBAC + ReBAC: For relationship-aware role checks
- RBAC + ABAC: For attribute-based exceptions to role permissions

Authorization models aren't mutually exclusive. Begin with manageable RBAC implementation, then incorporate relationships or attributes only when necessary complexity arises. Your initial focus should be on correctness, not premature flexibility.

Source: Hacker News discussion (https://news.ycombinator.com/item?id=45159269)