Chapter 13 — Single sign-on configuration

Chapter 13 — Single sign-on configuration

Lesson map

Lesson 13 published. Map, example, EX049.

flowchart TD
  N0["Learning outcomes"]
  N1["13.1 Planning"]
  N2["13.2 Configure and test"]
  N3["13.3 Closing bypass paths"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX049"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["13.1 Planning"]
  N2["13.2 Configure and test"]
  N3["13.3 Closing bypass paths"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX049"]

[Learning outcomes]
    |
    v
[13.1 Planning]
    |
    v
[13.2 Configure and test]
    |
    v
[13.3 Closing bypass paths]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX049]

Learning outcomes

You will (1) plan an SSO connection; (2) configure and test it; (3) disable bypass paths.

13.1 Planning

The dental records supplier now supports SAML 2.0 single sign-on. Tomas plans the connection with Priya: which users are in scope, how roles map from directory groups, how to test, and how to roll back if sign-in fails. He schedules the change for a quiet afternoon and informs both surgeries. Planning matters because a broken sign-in for the records system stops clinical work, so the rollback plan, keeping local passwords active until testing finishes, is written before any setting is changed.

13.2 Configure and test

Tomas follows the supplier's guide, exchanging certificate and metadata between directory and records system, and assigns the role groups. He tests with three volunteers from different roles, checking each sees exactly what the role table says. One nurse sees the reports menu meant for managers, caused by a group mapped twice. He fixes the mapping and repeats the test. Testing with real role samples, rather than only an admin account, shows whether access matches the agreed design. He records each test result in the change record.

13.3 Closing bypass paths

Once single sign-on works for two weeks, Tomas disables local password sign-in for staff in the records system, leaving only the emergency admin with a local account stored securely. Otherwise staff could still sign in with old passwords, bypassing multi-factor authentication and leaver controls. He verifies by trying a local sign-in with a disabled test account and confirming it fails. A sign-on project is complete only when the old path is closed and that closure is checked. The verification is recorded in the change record.

Worked example

SAML SSO for dental records passes tests after a duplicate group mapping is fixed; local staff passwords are disabled two weeks later and verified.

Synthetic case. Systems and tests are synthetic; SAML 2.0 is a real source.

Errors and limits

Leaving local passwords active after SSO preserves a path around MFA and leaver controls.

Exercises

• EX049 — Rollback plan. What was the rollback plan? Rubric: 3 = keep local passwords active until testing finished;; 2 = local passwords;; 1 = vague;; 0 = none.
• EX050 — Test finding. What did testing find? Rubric: 3 = a nurse saw manager reports from a double-mapped group;; 2 = mapping;; 1 = vague;; 0 = none.
• EX051 — Bypass risk. Why disable local passwords? Rubric: 3 = they bypass MFA and leaver controls;; 2 = bypass;; 1 = cost;; 0 = none.
• EX052 — Local exception. Which account keeps a local sign-in? Rubric: 3 = emergency admin;; 2 = emergency;; 1 = all;; 0 = none.

Synthesis

Planned, role-tested SSO with the old sign-in path closed brings systems under central control.

Continue studying — chapter 13 of 18

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