Chapter 6 — Identity and access fundamentals

Chapter 6 — Identity and access fundamentals

Lesson map

Lesson 06 published. Map, example, EX016.

flowchart TD
  N0["Learning outcomes"]
  N1["6.1 Three steps"]
  N2["6.2 Least privilege"]
  N3["6.3 Applying it to roles"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX016"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["6.1 Three steps"]
  N2["6.2 Least privilege"]
  N3["6.3 Applying it to roles"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX016"]

[Learning outcomes]
    |
    v
[6.1 Three steps]
    |
    v
[6.2 Least privilege]
    |
    v
[6.3 Applying it to roles]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX016]

Learning outcomes

You will (1) define identification, authentication and authorisation; (2) explain least privilege; (3) apply them to Fernhill roles.

6.1 Three steps

Identification is claiming who you are, such as typing a username. Authentication is proving it, with a password, passkey or other factor. Authorisation is deciding what the proven person may do. Kai explains that problems at any step matter: shared usernames break identification, weak passwords break authentication, and excessive group membership breaks authorisation. Separating the steps helps him diagnose issues, because a complaint like someone seeing records they should not is an authorisation problem, not a password problem. Kai uses this split in every later chapter of his placement.

6.2 Least privilege

Least privilege means giving each person the access their job needs and no more. A receptionist needs the booking system and client contact details, but not prescribing or payroll. A nurse needs clinical records but not finance. Kai compares each role's needs with current group memberships and finds that all reception staff are in vets-all, a shortcut from years ago that lets them edit clinical notes. Least privilege turns this from an unnoticed habit into a clear finding with an obvious fix.

6.3 Applying it to roles

Kai drafts a role table with Ruth: vet, nurse, receptionist, practice manager, finance, IT, and locum vet. For each role he lists required systems and permission levels, checked with a senior vet and the practice manager. He then maps roles to groups. The table becomes the reference for new starters, movers and reviews, so access decisions are based on agreed needs rather than copying a colleague's access, which tends to spread excess privilege through an organisation over time. Each role entry also records who signed it off and when.

Worked example

Kai's role table defines seven roles; comparing it with memberships shows all 22 receptionists in vets-all, which is corrected after sign-off.

Synthetic case. Roles, counts and findings are synthetic.

Errors and limits

Granting new staff the same access as a colleague spreads excessive privilege.

Exercises

• EX016 — Step type. Seeing records you should not see is which kind of problem? Rubric: 3 = authorisation;; 2 = access decision;; 1 = password;; 0 = none.
• EX017 — Reception finding. What did Kai find about receptionists? Rubric: 3 = all 22 in vets-all, able to edit clinical notes;; 2 = vets-all;; 1 = vague;; 0 = none.
• EX018 — Copying risk. Why avoid copying a colleague's access? Rubric: 3 = it spreads excess privilege;; 2 = spreads;; 1 = slow;; 0 = none.

Synthesis

Separating identification, authentication and authorisation, and applying least privilege by role, makes access deliberate.

Continue studying — chapter 06 of 30

← Chapter 05 (draft) · Course chapter index · Chapter 07 (draft) →