Chapter 31 — Identity and access management: implementation II | Engineering 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 31 — Identity and access management: implementation II

Lesson map

Lesson 31 published. Map, example, EX091.

flowchart TD
  N0["Learning outcomes"]
  N1["31.1 Department rollout"]
  N2["31.2 Legacy applications"]
  N3["31.3 Supplier access"]
  N4["31.4 Communication"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX091"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["31.1 Department rollout"]
  N2["31.2 Legacy applications"]
  N3["31.3 Supplier access"]
  N4["31.4 Communication"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX091"]

[Learning outcomes]
    |
    v
[31.1 Department rollout]
    |
    v
[31.2 Legacy applications]
    |
    v
[31.3 Supplier access]
    |
    v
[31.4 Communication]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX091]

Learning outcomes

You will (1) extend single sign-on and lifecycle to remaining departments; (2) onboard legacy and supplier access; (3) communicate change to staff.

31.1 Department rollout

After the pilot, Sana and the identity team roll out department by department, starting with smaller teams where problems affect fewer people. Each department follows the same checklist: confirm its applications and roles, enrol staff in passkeys during a supported week, enable report-only policies, review findings, enforce, and verify sign-in success and leaver removal. Keeping the checklist identical across departments means any difference in outcome points to something particular to that department, such as unusual devices, rather than to a change in method.

31.2 Legacy applications

About twenty applications cannot use modern federation. For some, an application proxy in front of the legacy system lets staff sign in through the provider, while the application still sees a simple header or form login behind the proxy. For others, Sana accepts scripted daily account exports compared against HR, with mismatches sent to the owner. Each legacy application gets a documented plan: proxy, scripted check or replacement, with a date. These are recorded as residual risk until the plan is complete, so they are not forgotten once the main rollout feels finished.

31.3 Supplier access

Suppliers who support council systems need access, but only to their own systems. Sana gives each supplier person an individual guest identity linked to a sponsor at the council, requires phishing-resistant authentication or the supplier's own strong sign-in through federation, restricts access to named applications and sets an expiry date tied to the contract. Sponsors confirm continued need every quarter. Shared supplier accounts, which existed for several systems, are removed, because actions under a shared account cannot be traced to a person.

31.4 Communication

Staff need to know what changes, when and what to do if something goes wrong. Before each department's rollout, the council sends a short notice with the date, a two-minute video showing passkey enrolment and a contact for help. Floor walkers from the IT team visit on enrolment day. After rollout, a brief follow-up asks staff for feedback. Clear communication reduces desk calls, helps staff report genuine problems quickly and builds goodwill, so security improvements are seen as making work easier rather than as obstacles.

Worked example

All departments are rolled out over five months with the same checklist; twenty legacy applications receive proxy, scripted-check or replacement plans; eleven shared supplier accounts are replaced by sponsored individual guest identities.

Synthetic case. Departments, applications and suppliers are synthetic.

Errors and limits

Leaving shared supplier accounts in place means supplier actions cannot be traced to individuals.

Exercises

EX091 — Identical checklist value. Why keep the rollout checklist identical across departments? Rubric: 3 = differences then point to department-specific causes;; 2 = comparability;; 1 = speed;; 0 = none.
EX092 — Legacy options. Name the three plan types for legacy applications. Rubric: 3 = proxy, scripted check, replacement;; 2 = two;; 1 = one;; 0 = none.
EX093 — Supplier sponsor. What does each supplier identity link to? Rubric: 3 = a council sponsor who confirms need quarterly;; 2 = sponsor;; 1 = contract only;; 0 = none.

Synthesis

A repeatable rollout, explicit legacy plans, sponsored supplier identities and clear communication carry the design across the whole council.

Continue studying — chapter 31 of 50

← Chapter 30 (draft) · Course chapter index · Chapter 32 (draft) →