Who is it for? Where does it live?
Identification turns a host or token into a tenant ID. Placement looks that ID up in the catalog. The request never names its stamp.
Bad: Trust the host or header
Anyone can type acme.app.example or send X-Tenant-Id.
Good: Route on hints, authorise on proof
The host picks the login page. The signed token’s tenant claim decides: mismatch, 403.
support.acme.com: prove, point, certify
- Acme publishes a fresh random TXT value
- Acme CNAMEs support.acme.com to acme.app.example
- Check TXT, CNAME and CAA, then order over ACME
- The edge picks that certificate by SNI
60 MB
the whole tenant map, for 200,000 tenants
At about 300 bytes an entry, it fits in every router’s memory. A lookup is a hash-map read, not a catalog call.
The tenant catalog goes down. Does every request fail?
Static stability
No. Routers keep serving the last good copy, with a copy on disk for restarts. Onboarding and moves wait; existing tenants keep working.
Acme moved to stamp-12. A router on the old map hasn’t heard.
stamp-07 won’t serve Acme or say 404. It answers 421 with the new home, and the router retries once.
A reset request says Host: evil.example. Where does the link point?
At the attacker, token and all, if links come from Host. Make the catalog the allow-list; build links from the tenant’s canonical host.
Remember
Which tenant? The signed token proves it, not the host. Where? The catalog’s map, pushed into every router’s memory.