Chapter 13 — Identity and access

Chapter 13 — Identity and access

Lesson map

Lesson 13 published. Map, example, EX037.

flowchart TD
  N0["Learning outcomes"]
  N1["13.1 Joiners, movers, leavers"]
  N2["13.2 Roles and duties"]
  N3["13.3 Stronger authentication"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX037"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["13.1 Joiners, movers, leavers"]
  N2["13.2 Roles and duties"]
  N3["13.3 Stronger authentication"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX037"]

[Learning outcomes]
    |
    v
[13.1 Joiners, movers, leavers]
    |
    v
[13.2 Roles and duties]
    |
    v
[13.3 Stronger authentication]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX037]

Learning outcomes

You will (1) design identity life-cycle processes for joiners, movers and leavers; (2) apply role-based access with separation of duties; (3) strengthen authentication with phishing-resistant methods.

13.1 Joiners, movers, leavers

Most access problems found in chapter 12 came from the identity life cycle. New staff were given access by copying a colleague's account, moving staff kept old rights and leavers' accounts stayed active for weeks. Lucas designs processes: joiners receive access from role definitions approved by managers; movers lose old roles when gaining new ones; leavers are disabled on their last day, triggered by the HR system. Each step is logged. Life-cycle processes prevent access from growing silently, a pattern called privilege creep that undermines least privilege over time.

13.2 Roles and duties

Lucas defines roles for Fernway: store staff, store manager, warehouse operator, buyer, finance clerk and administrator. Each role has a documented set of permissions. He checks for toxic combinations: a buyer who can also approve supplier payments could create a fake supplier and pay it. He marks such pairs as conflicts that cannot be held together, implementing separation of duties. Roles simplify access reviews, because managers review role assignments rather than hundreds of individual permissions. But roles need maintenance, or exceptions accumulate until roles mean little.

13.3 Stronger authentication

Fernway staff use passwords plus text-message codes. Lucas explains that text codes can be phished through fake login pages that relay codes in real time. Phishing-resistant methods, such as passkeys or hardware security keys using public-key cryptography bound to the real website, prevent this because the credential will not work on a fake domain. He proposes passkeys for administrators and finance staff first, then others. He also recommends that the member shop offer passkeys as an option. Authentication strength should follow the value of what an account can do.

Worked example

Lucas designs joiner-mover-leaver processes, defines six roles with one toxic combination blocked and proposes phishing-resistant authentication for privileged staff first.

Synthetic case. Roles and processes are synthetic.

Errors and limits

Role models drift without regular review. Passkey recovery processes can become a weak point.

Exercises

• EX037 — Privilege creep. What is privilege creep and which process prevents it? Rubric: 3 = access accumulating over moves; mover process removes old roles;; 2 = both;; 1 = vague;; 0 = none.
• EX038 — Toxic combination. What toxic combination did Lucas block? Rubric: 3 = buyer who can also approve supplier payments;; 2 = named;; 1 = vague;; 0 = none.
• EX039 — Text-code weakness. Why are text-message codes weaker than passkeys? Rubric: 3 = they can be phished and relayed in real time; passkeys bind to the real site;; 2 = relay;; 1 = stronger;; 0 = none.

Synthesis

Identity architecture controls the whole access life cycle, separates conflicting duties and matches authentication strength to account power.

Continue studying — chapter 13 of 40

← Chapter 12 (draft) · Course chapter index · Chapter 14 (draft) →