Identity security / Deception lab
Deceptive Identity Architecture
A self-hosted lab that connects an Authentik identity perimeter to Canarytokens and a Python enrichment service, to study whether a deliberate identity tripwire can produce higher-signal evidence than a general-purpose honeypot.
A proof of concept, not a production identity control. Not load tested, not hardened for multi-tenant use, and not a replacement for authentication or monitoring.
Claim
A deliberately placed identity tripwire can connect SSO activity to a structured, enriched audit record in a controlled lab.
Evidence
Repository configuration, Authentik customization, a self-hosted Canarytokens stack, the processing code, and captured lab output.
Boundary
The webhook receiver and IP heuristic are not production hardened. Attribution, delivery integrity, and failure handling need more work.
The problem
Honeypots are noisy. Identity tripwires are not.
A network honeypot collects broad activity, and with it noise and maintenance. This lab explores a narrower design: place a token at an identity boundary that no legitimate user should ever touch, then preserve any activation as a reviewable, enriched event.
An activation is treated as a high-priority signal that still needs context and source validation, not as proof of a specific attacker.
Architecture
From identity boundary to enriched event.
- Control Authentik SSO Central identity perimeter for simulated applications.
- Tripwire Canarytoken Hidden resource placed inside the identity experience.
- Route Secure tunnel External callback delivered into the isolated lab network.
- Process Flask service Extracts event fields and appends structured JSONL for SIEM ingestion.
- Enrich Threat context Adds geolocation and AbuseIPDB reputation for the reviewer.
Constraints
The environment forced real systems work.
No ARM64 images existed
Canarytokens had to be compiled natively on AArch64 rather than pulled from a registry.
Virtualized storage broke container permissions
VirtioFS and Alpine ownership behavior caused volume and database failures that required host and container configuration changes.
Cryptographic inputs had strict formats
Seed and base64 constraints in the deception stack had to match the backend library exactly. Placeholder values failed at initialization.
Proxies obscured source IPs
Tunnels and Docker networking replaced or mixed source addresses, so the processor scans the full payload for globally routable IPv4 candidates instead of trusting one header. That heuristic is itself a documented limitation.
Security review of my own prototype
Where the current code falls short.
- Source attribution. Picking the first routable IPv4 from the payload can misattribute when several addresses are present.
- Webhook authenticity. The receiver does not verify signed webhooks or require separate authentication.
- Cleartext lookup. The geolocation call uses HTTP. A revision should use an authenticated HTTPS provider or drop the lookup.
- Silent failures. Broad exception handling keeps the lab running but can hide enrichment and file-write errors.
- External dependencies. AbuseIPDB and tunnel providers add availability, privacy, and rate-limit dependencies.
- Token disclosure. Assets containing a live token URL are deliberately excluded from this portfolio.
The API key lives in an environment variable, and output is append-only JSONL that a SIEM can ingest directly. Hardening steps toward a deployable service are tracked in the repository.
Source
Inspect it yourself.
The architecture, configuration, and processing code are public, along with the documented limitations above.