Chapter 7 — Identity and access foundations
Lesson map
Lesson 07 published. Map, example, EX019.
flowchart TD
N0["Learning outcomes"]
N1["7.1 Authentication and authorization"]
N2["7.2 Keys and accounts"]
N3["7.3 Roles for credit issuing"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX019"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["7.1 Authentication and authorization"]
N2["7.2 Keys and accounts"]
N3["7.3 Roles for credit issuing"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX019"]
[Learning outcomes]
|
v
[7.1 Authentication and authorization]
|
v
[7.2 Keys and accounts]
|
v
[7.3 Roles for credit issuing]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX019]
Learning outcomes
You will (1) distinguish authentication from authorization; (2) manage keys and accounts; (3) design roles for credit issuing.
7.1 Authentication and authorization
Authentication confirms identity; authorization decides permissions. Staff log in to the booking system with passwords and a second factor, while members authenticate to the ledger by signing transactions with their wallet keys. The credit contract then checks authorization: only the issuer role can grant credits, and members can only spend their own. Lucas notes that a ledger cannot tell whether the right person holds a key, only whether the right key signed. So protecting keys and staff accounts is where identity security really lives for the makerspace and its credit system.
7.2 Keys and accounts
Lucas inventories every account and key: staff logins, administrator accounts on servers, node keys and the issuer key. For each he records the owner, purpose, storage and when it was last reviewed. He finds an old account belonging to a volunteer who left last year and has it disabled. He recommends the issuer key move from a laptop file to a hardware device. Inventories reveal forgotten access, which is a common route to problems. He schedules a review every quarter and adds account removal to the volunteer departure checklist.
7.3 Roles for credit issuing
Lucas designs roles with the manager. Workshop leaders can record workshops taught in the booking system. The coordinator approves them. A small issuing service prepares credit grants, and a 2-of-3 multisig of staff signs them on the ledger. An administrator role, behind a timelock, can change roles. Each role has only the powers it needs. The OWASP Smart Contract Top 10 lists access control failures as a leading weakness, so he documents roles clearly and asks the developer to add tests showing that each forbidden action is refused.
Worked example
Lucas disables a departed volunteer's account, moves the issuer key toward hardware and places credit grants behind a 2-of-3 staff multisig.
Synthetic case. The accounts, keys and roles are synthetic; the OWASP Smart Contract Top 10 is a real source.
Errors and limits
Forgotten accounts of departed volunteers remain a route to unauthorised access.
Exercises
- EX019 — Ledger limitation. What can the ledger not tell? Rubric: 3 = whether the right person holds the key;; 2 = who holds the key;; 1 = the balance;; 0 = none.
- EX020 — Inventory finding. What did the inventory reveal? Rubric: 3 = an account of a volunteer who left;; 2 = old account;; 1 = vague;; 0 = none.
- EX021 — Grant signing. Who signs credit grants on the ledger? Rubric: 3 = a 2-of-3 multisig of staff;; 2 = multisig;; 1 = one leader;; 0 = none.
Synthesis
Inventories and least-privilege roles turn identity theory into protection.
Continue studying — chapter 07 of 30
← Chapter 06 (draft) · Course chapter index · Chapter 08 (draft) →