Chapter 19 — Identity and cryptography | 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 19 — Identity and cryptography

Lesson map

Lesson 19 published. Map, example, EX055.

flowchart TD
  N0["Learning outcomes"]
  N1["19.1 Signatures and trust"]
  N2["19.2 Token contents"]
  N3["19.3 Certificates"]
  N4["19.4 Key lifecycle"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX055"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["19.1 Signatures and trust"]
  N2["19.2 Token contents"]
  N3["19.3 Certificates"]
  N4["19.4 Key lifecycle"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX055"]

[Learning outcomes]
    |
    v
[19.1 Signatures and trust]
    |
    v
[19.2 Token contents]
    |
    v
[19.3 Certificates]
    |
    v
[19.4 Key lifecycle]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX055]

Learning outcomes

You will (1) explain keys, certificates and signatures in identity; (2) describe token formats and signing; (3) plan key lifecycle.

19.1 Signatures and trust

Identity federation relies on digital signatures. The identity provider signs assertions and tokens with its private key; applications verify them with the matching public key. If verification succeeds, the application knows the token came from the provider and was not altered. SAML 2.0, an OASIS standard, uses signed XML assertions; OpenID Connect uses signed JSON Web Tokens defined in RFC 7519. Sana explains that the whole system's trust rests on the secrecy of the provider's signing keys and on applications actually checking signatures.

19.2 Token contents

A JSON Web Token carries claims: who the user is, who issued the token, which application it is for, when it was issued and when it expires. Applications must check all of these, not only the signature. A valid token issued for a different application should be rejected, and an expired one refused. Sana lists the checks required of every integration and includes them in policy tests, because skipping the audience or expiry check is a common integration mistake that makes valid tokens dangerous.

19.3 Certificates

Certificates bind public keys to names and are used for TLS on the provider's sign-in pages and sometimes for signing keys. Each has an expiry date. An expired signing certificate can stop sign-in to every federated application at once, which has caused outages in many organisations. Sana inventories every certificate in the identity system with owner, expiry and renewal procedure, and sets alerts well in advance. Renewal is rehearsed in the test tenant so it is routine rather than an emergency.

19.4 Key lifecycle

Signing keys pass through generation, publication, use, rotation and retirement. Rotation limits damage if a key leaks and keeps the procedure practised. Providers usually publish their current public keys at a well-known address, so applications can fetch new ones automatically. Sana checks that each application does so, rather than having a key copied into its configuration by hand, because hand-copied keys break silently at rotation. Revocation is also planned, so a compromised key can be withdrawn quickly. Each step has a named owner and a rehearsed procedure.

Worked example

Sana's integration checklist requires signature, issuer, audience and expiry checks; her certificate inventory shows two signing certificates expiring within ninety days, both scheduled for rehearsed renewal.

Synthetic case. Certificates and checks are synthetic.

Errors and limits

Checking only a token's signature, not its audience and expiry, accepts tokens meant for other applications or already expired.

Exercises

EX055 — JWT standard. Which RFC defines JSON Web Tokens? Rubric: 3 = RFC 7519;; 2 = 7519;; 1 = 6749;; 0 = none.
EX056 — Required checks. Which four token checks does Sana require? Rubric: 3 = signature, issuer, audience, expiry;; 2 = three;; 1 = signature only;; 0 = none.
EX057 — Hand-copied keys. Why avoid hand-copying signing keys into applications? Rubric: 3 = they break silently at rotation;; 2 = rotation;; 1 = size;; 0 = none.

Synthesis

Signatures, complete token checks, managed certificates and automated key rotation keep federation trustworthy.

Continue studying — chapter 19 of 50

← Chapter 18 (draft) · Course chapter index · Chapter 20 (draft) →