Chapter 4 — Scripting for identity tasks | Technical 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 4 — Scripting for identity tasks

Lesson map

Lesson 04 published. Map, example, EX013.

flowchart TD
  N0["Learning outcomes"]
  N1["4.1 Why script"]
  N2["4.2 Parsing exports"]
  N3["4.3 Testing"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX013"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["4.1 Why script"]
  N2["4.2 Parsing exports"]
  N3["4.3 Testing"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX013"]

[Learning outcomes]
    |
    v
[4.1 Why script]
    |
    v
[4.2 Parsing exports]
    |
    v
[4.3 Testing]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX013]

Learning outcomes

You will (1) write safe read-only scripts; (2) parse directory exports; (3) test against known data.

4.1 Why script

Many identity checks repeat: who has not signed in recently, who lacks multi-factor authentication, which accounts have no owner. Doing them by hand each month is slow and error-prone. Tomas learns to write small Python scripts with the standard library that read exported CSV files and print reports. Priya sets one rule: scripts in this course only read exports and print results; they never change accounts. Changes are made by a person in the admin console after reviewing the report.

4.2 Parsing exports

Directory exports contain dates, usernames and flags in formats that vary. Tomas writes functions that read each column carefully: converting date strings to dates, trimming spaces and treating empty cells as unknown rather than as false. He learns that an empty last sign-in date may mean never signed in, which matters for new accounts. Careful parsing prevents a script from reporting a healthy account as stale, or missing a stale one, simply because a date was formatted differently. He adds comments explaining each rule for the next reader.

4.3 Testing

Before running a script on a real export, Tomas builds a small synthetic file with known answers: one stale account, one without an owner, one disabled account that should be ignored. He runs the script and compares output with the expected answers. When a disabled account appears in the stale list, he fixes the filter. Testing against known data is quick and catches mistakes before they reach a manager who might act on wrong information. He keeps the test file beside the script so it can be rerun after any change.

Worked example

Tomas's first script fails a test by listing a disabled account as stale; after a fix, all known answers match.

Synthetic case. Scripts and data are synthetic.

Errors and limits

Writing scripts that change accounts directly removes the human review step that catches mistakes.

Exercises

EX013 — Script rule. What rule does Priya set for scripts? Rubric: 3 = read exports and print only, no changes;; 2 = read-only;; 1 = anything;; 0 = none.
EX014 — Empty date. What might an empty last sign-in date mean? Rubric: 3 = never signed in;; 2 = new account;; 1 = deleted;; 0 = none.
EX015 — Test bug. What bug did testing reveal? Rubric: 3 = disabled account listed as stale;; 2 = disabled;; 1 = vague;; 0 = none.
EX016 — Change path. How are changes made after a report? Rubric: 3 = by a person in the admin console;; 2 = manually;; 1 = script;; 0 = none.

Synthesis

Read-only, tested scripts make repeated identity checks fast and reliable.

Continue studying — chapter 04 of 18

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