Chapter 32 — Identity and access management: reliability
Lesson map
Lesson 32 published. Map, example, EX094.
flowchart TD
N0["Learning outcomes"]
N1["32.1 Availability model"]
N2["Lab — Sign-in availability"]
N3["32.2 Reading the model"]
N4["32.3 Independence"]
N5["32.4 Emergency access"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX094"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["32.1 Availability model"]
N2["Lab — Sign-in availability"]
N3["32.2 Reading the model"]
N4["32.3 Independence"]
N5["32.4 Emergency access"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX094"]
[Learning outcomes]
|
v
[32.1 Availability model]
|
v
[Lab — Sign-in availability]
|
v
[32.2 Reading the model]
|
v
[32.3 Independence]
|
v
[32.4 Emergency access]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX094]
Learning outcomes
You will (1) model availability of sign-in; (2) identify single points of failure; (3) check independence of redundant parts.
32.1 Availability model
When the identity provider sits in front of every application, its availability, and that of the paths to it, bounds the availability of everything. Sana models sign-in for a typical cloud application as components in series: the council's internet link, the provider's service region and the application itself. Components in series multiply their availabilities, so the chain is less available than any one part. Redundant parts in parallel improve availability, since both must fail together for the service to stop. The model shows where investment would reduce downtime most.
Lab — Sign-in availability
"""Availability of sign-in for a council application: components in series and in parallel (stdlib only)."""
hrs = 8760
comp = {"internet": 0.9990, "provider-region": 0.9995, "hr-feed": 0.9900, "app": 0.9980}
link2 = 0.9970
series = comp["internet"] * comp["provider-region"] * comp["app"]
dual = 1 - (1 - comp["internet"]) * (1 - link2)
with_dual = dual * comp["provider-region"] * comp["app"]
print(f"single link: A={series:.4f} downtime_h={hrs*(1-series):.1f}")
print(f"dual links: A={with_dual:.4f} downtime_h={hrs*(1-with_dual):.1f}")
print("hr-feed is not in the sign-in path; its outage delays joiners/leavers, not sign-in")
Run with python3 lab_avail.py. Verified output:
single link: A=0.9965 downtime_h=30.6
dual links: A=0.9975 downtime_h=21.9
hr-feed is not in the sign-in path; its outage delays joiners/leavers, not sign-in
32.2 Reading the model
With a single internet link, the synthetic model gives availability of 0.9965, about thirty hours of sign-in downtime a year. Adding a second link from a different provider raises it to 0.9975, about twenty-two hours. The remaining downtime comes mostly from the application and the provider region, which the council does not control. The HR feed is not in the sign-in path at all: its outage delays joiners and leavers rather than stopping sign-in. Sana presents results as hours per year, which directors understand far more easily than percentages.
32.3 Independence
Redundancy only helps if failures are independent. Two internet links leaving the building through the same duct, or relying on the same upstream carrier, can fail together. Two provider regions might share a software release that fails everywhere at once. Sana checks for shared causes and records them, because the simple model overstates availability when parts share dependencies. Where independence cannot be achieved, she states the risk plainly in the report rather than letting an optimistic number speak for itself.
32.4 Emergency access
Even with redundancy, the provider may become unreachable. Sana designs emergency access for critical services: a small number of emergency administrator accounts with phishing-resistant keys stored in a safe, excluded from conditional policies, and local break-glass procedures for systems such as the emergency planning application. Use triggers alerts and a review. These arrangements are tested twice a year. Emergency access is a reliability control, but it is also a security risk, so it is kept minimal, monitored and documented. Each test result is recorded as evidence.
Worked example
A second internet link reduces modelled sign-in downtime from about 30.6 to 21.9 hours a year; shared-duct risk is recorded, and emergency access is designed and tested twice yearly.
Synthetic case. Availabilities, links and procedures are synthetic.
Errors and limits
Assuming redundant links are independent when they share a duct or carrier overstates availability.
Exercises
- EX094 — Single-link downtime. What annual downtime does the single-link model give? Rubric: 3 = about 30.6 hours, A=0.9965;; 2 = 30 hours;; 1 = 22;; 0 = none.
- EX095 — HR feed placement. Why does an HR feed outage not stop sign-in? Rubric: 3 = it is not in the sign-in path, only lifecycle;; 2 = not in path;; 1 = it does;; 0 = none.
- EX096 — Emergency testing. How often is emergency access tested? Rubric: 3 = twice a year;; 2 = regularly;; 1 = never;; 0 = none.
Synthesis
Availability models, independence checks and minimal, tested emergency access keep central sign-in reliable.
Continue studying — chapter 32 of 50
← Chapter 31 (draft) · Course chapter index · Chapter 33 (draft) →