Access Control

AOH Sync uses role-based access control (RBAC): people are placed in groups, groups map to roles, and roles define what is permitted. You manage access by managing membership, not by granting permissions one at a time.

Groups, roles, and grants

• A group is a collection of people, mirrored from your directory or managed in AOH Sync.
• A role defines what is allowed. Each role carries three kinds of grant:

  • Granted routes - which parts of the UI a person can reach.
  • Granted API access - which API operations a person can perform.
  • Granted data access - which data a person can see.
• Groups map to roles. Belonging to a group confers its roles' grants.

You change access by changing the group-to-role matrix, not by editing individuals.

Backend-authoritative

Every access decision is made on the server, on every request. The UI asks the backend and reflects the answer:

• A protected operation is checked against your roles before it runs. Reaching the page passes no check.
• If your access is revoked, the next request is denied. There is no stale-UI window.
• You cannot grant yourself access by manipulating the interface; it was never the authority.

When frontend and backend disagree, the backend is correct by definition.

Adding roles

New roles are defined deliberately (a defined entry plus the corresponding data change), not improvised at runtime, so the set of roles is always something you can enumerate and review.

What this means

If someone has access they should not, the fix is in the role and group model, in one place, and takes effect immediately. There are no stray per-user grants to hunt for. Every change is recorded in the audit trail.