A persona may act because of its role, and no other reason

Source: acme_role_and_permission_model.puml. Regenerate with plantuml -tpng doc/knowledge/demo/acme_role_and_permission_model.puml.

An account holds roles, a role bundles permissions, and an operation checks the code it names. The chain has no shortcut, and the two exceptions are both deliberate. TenantAdmin holds the single permission *, which satisfies every check in the tenant, and a service account holds its component's wildcard, which is why a service can write what no person may. Role-Based Access Control states the model, and Identity and Access orders the pages that carry it.

Seven job roles across 73 staff, and one administrator account the profile creates outside the staff datasets. A persona holds exactly one job role, so the matrix below has one row per persona.

The empty cells are the point of the table, and three of them carry a decision.

• Member holds none of the inbox codes, so the approvals queue is not a screen every person sees. It is a screen for the functions that decide, and a member with no decide role reads an empty queue.
• The Controller and Finance roles hold no marketdata code. Deciding a book change does not require reading the party's market data feeds, and the demonstration keeps the two apart.
• The row for iam::roles:assign is empty for every job role. The only holder is TenantAdmin, through its *, so the decision on a role request stays with the administrator. Role requests states why that write is administrative.

A permission is necessary and not sufficient. Two further rules sit above the codes, and both are enforced in the database rather than in a screen.

• Four eyes. A person never decides a request they raised. The decisions table refuses the row, and the queue cuts the person's own requests out of the page before it is paged, so the refusal is rarely reached.
• One decision per person. A request that needs two approvals, or several parts, takes one decision from each person whatever part they answered for, so two roles held by one account do not let it approve twice.

Approval requests states both, and the approval model applies them to the kinds the demonstration seeds.

Three limits are worth stating because a reader will ask.

• A job role is per tenant. A person of the Acme tenant holds an Acme role and reads nothing of another tenant, whatever the role's name.
• A role does not select a party. The demonstration gives each person a default party, and a read that is party-scoped sees that party and its children, so a controller in London decides a London book for the same reason a London trader books into it.
• A role cannot change itself. Adding a permission to a role is an IAM write, held by the administrator, and granting a role to a person is the same write.