Chapter 21 — Provisioning with SCIM
Lesson map
Lesson 21 published. Map, example, EX061.
flowchart TD
N0["Learning outcomes"]
N1["21.1 Why automate"]
N2["21.2 SCIM in brief"]
N3["21.3 Safe automation"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX061"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["21.1 Why automate"]
N2["21.2 SCIM in brief"]
N3["21.3 Safe automation"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX061"]
[Learning outcomes]
|
v
[21.1 Why automate]
|
v
[21.2 SCIM in brief]
|
v
[21.3 Safe automation]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX061]
Learning outcomes
You will (1) explain automated provisioning; (2) describe SCIM at a high level; (3) plan safe automation.
21.1 Why automate
Manual account creation and removal relies on someone remembering every step for every system. Automated provisioning lets the directory create, update and disable accounts in connected services when a person's record changes. For Fernhill this means the booking system and practice management system receive changes within minutes, without IT typing them twice. Kai explains that automation reduces errors and delays, but only if the source data is accurate, which is why HR data quality came first. Kai lists the systems that support automation and those that do not.
21.2 SCIM in brief
SCIM, the System for Cross-domain Identity Management, defined in RFC 7644, is a standard way for a directory to send user and group changes to services. Kai checks that the practice management system supports SCIM in its current version; it does, for users but not groups. He plans to use SCIM for account creation and disablement, and to manage that system's internal permissions from role mappings maintained in a simple table reviewed by the senior vet. The mapping table is part of the documentation index.
21.3 Safe automation
Kai tests provisioning on a staging copy with synthetic staff first. He sets the connection so that accounts are disabled, not deleted, when removed from scope, which avoids losing records through a mistake. He starts with one clinic, compares results with the role table and widens scope after two clean weeks. Every automated change is logged. Automation spreads mistakes as quickly as it spreads correct changes, so careful staging is part of the design. Kai records each pilot finding and its fix for the handover pack.
Worked example
SCIM provisioning to the practice management system is piloted at one clinic for two weeks, disabling rather than deleting removed accounts.
Synthetic case. Systems and the pilot are synthetic; RFC 7644 is a real source.
Errors and limits
Turning on automated deletion across all clinics at once risks spreading one mistake everywhere.
Exercises
- EX061 — Automation dependency. What must be true for automation to help? Rubric: 3 = source data must be accurate;; 2 = accurate HR;; 1 = fast network;; 0 = none.
- EX062 — SCIM standard. Which RFC defines the SCIM protocol? Rubric: 3 = RFC 7644;; 2 = 7644;; 1 = 6749;; 0 = none.
- EX063 — Removal behaviour. What happens to removed accounts? Rubric: 3 = disabled, not deleted;; 2 = disabled;; 1 = deleted;; 0 = none.
Synthesis
Standards-based, staged provisioning reduces manual errors when source data is accurate.
Continue studying — chapter 21 of 30
← Chapter 20 (draft) · Course chapter index · Chapter 22 (draft) →