Chapter 9 — Single sign-on | Technologist Identity and access management

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 9 — Single sign-on

Lesson map

Lesson 09 published. Map, example, EX025.

flowchart TD
  N0["Learning outcomes"]
  N1["9.1 What SSO does"]
  N2["9.2 SAML and OpenID Connect"]
  N3["9.3 Bringing systems on"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX025"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["9.1 What SSO does"]
  N2["9.2 SAML and OpenID Connect"]
  N3["9.3 Bringing systems on"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX025"]

[Learning outcomes]
    |
    v
[9.1 What SSO does]
    |
    v
[9.2 SAML and OpenID Connect]
    |
    v
[9.3 Bringing systems on]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX025]

Learning outcomes

You will (1) explain single sign-on; (2) describe SAML and OpenID Connect at a high level; (3) plan bringing systems onto SSO.

9.1 What SSO does

Single sign-on lets staff sign in once to the directory and then reach connected services without separate passwords. For Fernhill this means fewer passwords for staff, one place to apply multi-factor authentication and one place to disable access for leavers. Kai explains that SSO concentrates trust in the directory, so protecting directory sign-in becomes even more important. That is why the passkey plan and SSO plan go together: a strong front door protects every service connected behind it. Kai also notes that signing out of the directory should end connected sessions.

9.2 SAML and OpenID Connect

Two common standards connect services to a directory. SAML 2.0, from OASIS, passes signed statements about the user from the directory to the service. OpenID Connect, built on OAuth 2.0 (RFC 6749), does a similar job using tokens and is common in newer web and mobile services. Kai does not need to build either; he needs to know which each service supports, configure them using the supplier's documentation, and test that signing in and signing out work correctly. He keeps a short record of which standard each service uses.

9.3 Bringing systems on

Kai asks the practice management supplier and the payroll supplier whether they support SSO. The practice management system supports SAML in its current version; payroll does not. He plans to connect the practice management system after a test with five volunteer staff, keeping local accounts disabled once SSO works. Payroll stays separate, with its own multi-factor authentication and a leaver checklist entry, and he notes it as a known gap to revisit at contract renewal. The pilot volunteers come from two clinics and include a receptionist and a vet.

Worked example

The practice management system moves to SAML SSO after a five-person pilot; payroll remains separate with MFA and a checklist entry.

Synthetic case. Systems and suppliers are synthetic; SAML 2.0, OpenID Connect Core and RFC 6749 are real sources.

Errors and limits

Leaving local accounts active after SSO is enabled preserves a separate path that leaver removal can miss.

Exercises

EX025 — SSO benefit. Name one benefit of SSO for leavers. Rubric: 3 = one place to disable access;; 2 = one place;; 1 = speed;; 0 = none.
EX026 — OIDC basis. What is OpenID Connect built on? Rubric: 3 = OAuth 2.0, RFC 6749;; 2 = OAuth;; 1 = SAML;; 0 = none.
EX027 — Payroll gap. How is payroll handled? Rubric: 3 = separate with MFA and leaver checklist entry;; 2 = separate;; 1 = SSO;; 0 = none.

Synthesis

SSO reduces passwords and centralises control, provided directory sign-in is strongly protected.

Continue studying — chapter 09 of 30

← Chapter 08 (draft) · Course chapter index · Chapter 10 (draft) →