Chapter 8 — Computer architecture | 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 8 — Computer architecture

Lesson map

Lesson 08 published. Map, example, EX022.

flowchart TD
  N0["Learning outcomes"]
  N1["8.1 Secure hardware"]
  N2["8.2 Cost of cryptography"]
  N3["8.3 Memory and sessions"]
  N4["8.4 Sizing servers"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX022"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["8.1 Secure hardware"]
  N2["8.2 Cost of cryptography"]
  N3["8.3 Memory and sessions"]
  N4["8.4 Sizing servers"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX022"]

[Learning outcomes]
    |
    v
[8.1 Secure hardware]
    |
    v
[8.2 Cost of cryptography]
    |
    v
[8.3 Memory and sessions]
    |
    v
[8.4 Sizing servers]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX022]

Learning outcomes

You will (1) explain how secure hardware stores keys; (2) relate processor and memory to cryptographic cost; (3) size identity servers sensibly.

8.1 Secure hardware

Identity systems rely on hardware that protects keys. Trusted platform modules in laptops, secure enclaves in phones and hardware security modules in data centres keep private keys inside protected boundaries and perform signing there, so software outside never sees the key. The identity provider's token-signing key is the most valuable secret in Sana's design, because anyone holding it could create tokens accepted by every application. She plans to keep it in a hardware security module or a managed key service with equivalent protection, with access tightly logged.

8.2 Cost of cryptography

Every sign-in involves cryptographic operations: verifying a passkey signature, signing an ID token and checking certificates. Each consumes processor time. Elliptic-curve signatures are much faster to create than older RSA signatures of similar strength, which affects how many tokens per second a server can issue. Sana measures signing time on representative hardware in the lab rather than trusting general figures, because actual cost depends on the processor, the library and whether a hardware module is involved. The results feed directly into the sizing estimate in this chapter.

8.3 Memory and sessions

The identity provider keeps session state for signed-in users, such as which authentication methods were used and when the session expires. With 2,400 staff and some on several devices, sessions number in the thousands, each using a small amount of memory or database storage. Sana estimates this and checks what happens when the store fills or a server restarts. If sessions are lost on restart, every user must sign in again at once, creating a sudden load spike that the capacity plan must allow for.

8.4 Sizing servers

Combining peak sign-in rate, cryptographic cost per sign-in and session storage gives a server sizing estimate. Sana adds headroom for growth and for one server failing, so the remaining servers can carry the whole load. She documents the estimate with its assumptions and plans a load test in the verification laboratory. Sizing from measured costs rather than vendor marketing figures avoids both waste and the far worse outcome of a provider that collapses at the morning peak. The load test then confirms or corrects these figures.

Worked example

Measured signing at about 0.4 milliseconds per token and a peak of 28 sign-ins per second give modest processor load; Sana sizes for two servers, each able to carry the full peak alone.

Synthetic case. Measurements and servers are synthetic.

Errors and limits

Storing the token-signing key in an ordinary file on the server exposes the most valuable secret in the design.

Exercises

EX022 — Signing key value. Why is the token-signing key the most valuable secret? Rubric: 3 = anyone holding it can forge tokens every app accepts;; 2 = forge tokens;; 1 = encryption;; 0 = none.
EX023 — Restart spike. What happens if sessions are lost on restart? Rubric: 3 = all users sign in again, causing a load spike;; 2 = spike;; 1 = vague;; 0 = none.
EX024 — Failure headroom. How does Sana plan for one server failing? Rubric: 3 = each server can carry full peak alone;; 2 = headroom;; 1 = vague;; 0 = none.

Synthesis

Secure hardware protects keys, and measured cryptographic and session costs drive realistic sizing.

Continue studying — chapter 08 of 50

← Chapter 07 (draft) · Course chapter index · Chapter 09 (draft) →