Design an access control system (RBAC + resource-based)
Company: Atlassian
Role: Software Engineer
Category: System Design
Difficulty: medium
Interview Round: Onsite
Design an authorization system that supports both:
- **Role-Based Access Control (RBAC)**: users/groups have roles (e.g., Admin, Editor, Viewer) that grant permissions.
- **Resource-based permissions (ACLs)**: individual resources can grant permissions directly to users/groups (e.g., a specific page shared with a user).
Requirements:
- Support common actions: `read`, `write`, `delete`, `share`, `admin`.
- Must work across multiple resource types (spaces, pages, projects, issues).
- Provide APIs to grant/revoke access and to check authorization.
- Discuss policy evaluation, data model, caching, and audit logs.
Deliverables:
- Core entities and schema.
- Permission evaluation algorithm.
- REST APIs.
- Edge cases (deny overrides? inheritance? group membership changes?).
Overview: This question evaluates a candidate's ability to design a scalable authorization system incorporating RBAC and resource-based ACLs, testing competencies in access-control models, data schema design, policy evaluation, API design, caching strategies, and audit logging.
Read the full Atlassian Software Engineer interview experience this question came from
Community answers
Answer by freny07pethelis1996
`
name: RBAC and Resource ACL
overview: "Atlassian onsite: authorization with RBAC roles and per-resource ACLs. Check on the request path. Grant/revoke, inheritance, groups, cache, audit."
todos:
id: clarify
content: Lock deny vs default-deny, inheritance, group expansion
status: pending
id: schema
content: Principals, roles, bindings, ACL, resource parent, acl_gen
status: pending
id: check
content: Evaluate union of roles + ACL; page restrictions AND
status: pending
id: cache
content: Bitmask cache keyed by user+resource; bust on acl_gen
status: pending
id: drills
content: Deny overrides, group change, share, IDOR
status: pending
isProject: false
Access control — RBAC + resource ACL
Atlassian onsite (medium). Authorization (what you may do), not login. Support roles (Admin / Editor / Viewer) and per-resource grants (this page shared with Alice). Actions: read, write, delete, share, admin. Types: spaces, pages, projects, issues.
Interactive board: Access control (repo). Cursor live board: access-control-rbac-acl.canvas.tsx.
Pattern (same as rate limiter): lock decisions → one namespace (Postgres grants + acl_gen) → Check on the request path → cache / audit. HLD = talk-track; ### LLD = SQL / sequences.
Thesis: Check is a bitmask. Union role bindings on the container (space / project) with ACL rows on the resource (and ancestors). Default deny. Page/issue restrictions can only narrow (AND), not widen. Cache (user, resource) until acl_gen bumps. Grant/revoke is one Postgres txn