Chapter 21 — Cryptography and trust services: service integration
Lesson map
Lesson 21 published. Map, example, EX061.
flowchart TD
N0["Learning outcomes"]
N1["21.1 A new service arrives"]
N2["21.2 Onboarding checklist"]
N3["21.3 Verifying before go-live"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX061"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["21.1 A new service arrives"]
N2["21.2 Onboarding checklist"]
N3["21.3 Verifying before go-live"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX061"]
[Learning outcomes]
|
v
[21.1 A new service arrives]
|
v
[21.2 Onboarding checklist]
|
v
[21.3 Verifying before go-live]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX061]
Learning outcomes
You will (1) integrate a new service with council trust services; (2) define an onboarding checklist; (3) verify integration before go-live.
21.1 A new service arrives
The council buys a hosted booking system for community halls. It must use council single sign-on, present a valid certificate on a council subdomain, receive payment webhooks and store citizens' contact details. Rosa is asked to integrate it with the council's trust services. She starts by listing what the service needs from the council, such as a certificate and a webhook secret, and what the council needs from the supplier, such as TLS 1.2 or later, encryption at rest and a named security contact.
21.2 Onboarding checklist
Rosa turns her work into a reusable checklist: inventory entry with owner; certificate issued through ACME with monitoring; TLS configuration checked against the council baseline; webhook secret created in the secret store and shared with the supplier through a secure channel, never email; single sign-on configured with signed assertions validated by the supplier; data-at-rest encryption confirmed in the contract; and a rollback plan. Each item has a person who confirms it. The checklist means the next service onboards faster and more consistently.
21.3 Verifying before go-live
Before launch Rosa verifies each item with evidence rather than the supplier's word: she connects and records the TLS version and certificate chain, sends a test webhook with a deliberately wrong signature to confirm it is rejected, checks expiry monitoring shows the new certificate, and confirms sign-on fails when assertions are tampered with in the supplier's test environment. One check fails: the supplier accepted the wrong webhook signature. Go-live waits until the supplier fixes verification and Rosa retests successfully. She records the retest output in the change record before approving launch.
Worked example
Rosa integrates a hall-booking service using a checklist and blocks go-live when a negative webhook test shows the supplier accepted a bad signature.
Synthetic case. The service and supplier are invented.
Errors and limits
Checklists can become box-ticking; require evidence. Supplier test environments may differ from production.
Exercises
- EX061 — Secret sharing. How must the webhook secret be shared with the supplier? Rubric: 3 = through a secure channel from the secret store, never email;; 2 = secure;; 1 = email;; 0 = none.
- EX062 — Failed check. Which go-live check failed? Rubric: 3 = supplier accepted a webhook with a wrong signature;; 2 = webhook;; 1 = vague;; 0 = none.
- EX063 — Evidence. Why test with negative cases rather than trusting supplier statements? Rubric: 3 = statements can be wrong; negative tests prove rejection actually happens;; 2 = proof;; 1 = trust;; 0 = none.
Synthesis
Integrating a service means a checklist of trust requirements, each verified by evidence including negative tests, before go-live.
Continue studying — chapter 21 of 30
← Chapter 20 (draft) · Course chapter index · Chapter 22 (draft) →