Signando Keycloak
The Application Layer Gateway that protects Keycloak through OIDC grant type enforcement, SAML XXE prevention, Admin API protection, and token response validation.
What is Signando Keycloak?
Signando Keycloak is an Application Layer Gateway (ALG) that sits between your clients and your Keycloak identity provider. It validates every OIDC, SAML, and Admin API request through a 16-step security pipeline before forwarding it to Keycloak.
Signando Keycloak also validates every response from Keycloak through a 9-step response pipeline. This bidirectional validation ensures:
- Insecure OAuth2 flows (ROPC, implicit) are blocked before reaching Keycloak
- Admin API abuse (realm export, mass user operations) is prevented
- Token responses are validated for algorithm safety and claim leakage
- SAML XXE and signature wrapping attacks are stopped
Technical Specifications
| Language | 100% Rust |
| Latency | < 10ms (p99) |
| Security Tests | 102 Tests |
| Request Pipeline | 16 validation steps |
| Response Pipeline | 9 validation steps |
| Deployment | Docker / Kubernetes / Bare Metal |
The Paranoid Approach
Protocol-Aware Enforcement
Unlike generic WAFs, Signando Keycloak understands OAuth2, OIDC, and SAML protocols. It enforces PKCE, blocks insecure grant types, and validates redirect URIs against per-client whitelists.
4-Stage Isolation
Four separate processes communicate exclusively through NATS or Valkey brokers. Even if one stage is compromised, it cannot access other stages or the Keycloak backend directly.
Bidirectional Validation
Both requests and responses are validated. Token responses are checked for algorithm safety, claim leakage, and lifetime violations before reaching clients.
The 4 Processes in Detail
Each process is isolated and communicates exclusively through defined channels.
1. Keycloak Frontend
Accepts OIDC, SAML, and Admin API requests. Extracts realm, client_id, and classifies the OAuth2 flow.
Input
- HTTP/HTTPS requests on Port 8443
- OIDC, SAML, Admin API, Account Console
- Realm and client_id extraction from URL/body
Output
- Writes request data to Channel 1 (Request Dirty)
- Reads validated responses from Channel 4 (Response Clean)
- Sends HTTP response to client
🔒 Security Rules
- No direct connection to Keycloak backend
- Health check on separate port (9090)
- LIFO partition allocation for connection management
- Per-IP and per-client rate limiting
2. Request Validator
16-step validation pipeline: OIDC grant types, scopes, PKCE, SAML XXE, Admin API protection, and more.
Input
- Reads request data from Channel 1 (Request Dirty)
- Loads TOML policy configuration
Output
- Writes validated requests to Channel 2 (Request Clean)
- Or: blocked request signal (OAuth2 JSON error)
🔒 Security Rules
- No HTTP server: Opens no ports, only polls the message channel
- Grant type enforcement (blocks ROPC, implicit by default)
- Per-client scope and redirect URI whitelists
- PKCE enforcement (S256 only, blocks plain method)
- SAML XXE prevention (DOCTYPE blocking)
- Admin API endpoint whitelist + master realm blocking
- SQL injection and XSS detection
3. Keycloak Backend
Forwards validated requests to the upstream Keycloak server and collects its responses.
Input
- Reads validated requests from Channel 2 (Request Clean)
Output
- Calls Keycloak on Port 8080 (configurable)
- Writes response to Channel 3 (Response Dirty)
🔒 Security Rules
- No direct connection to client (only via message channels)
- Backend connection only to configured Keycloak host
- Never follows HTTP redirects from upstream (3xx passed through)
- Configurable timeout (default 30s)
4. Response Validator
9-step response validation: JWT algorithm enforcement, token lifetime, claim leakage detection, security headers.
Input
- Reads responses from Channel 3 (Response Dirty)
Output
- Writes validated responses to Channel 4 (Response Clean)
- On error: Generates safe OAuth2 error response
🔒 Security Rules
- No HTTP server: Opens no ports, only polls the message channel
- JWT algorithm enforcement (blocks 'none', standalone HS256)
- Token lifetime validation (configurable max, default 24h)
- Claim leakage detection (blocked claims list)
- Security header enforcement (HSTS, CSP, X-Frame-Options)
- Server version removal (prevents banner grabbing)
Data Flow Overview
┌──────────────────────────────────────────────────────────────────────────────┐ │ │ │ Client ──▶ KC Frontend ──▶ Ch. 1 ──▶ Request ──▶ Ch. 2 ──▶ KC Backend │ │ │ (8443) (Dirty) Validator (Clean) │ │ │ │ │ │ │ │ ▼ │ │ │ Keycloak │ │ │ (8080) │ │ │ │ │ │ │ ┌─────────────────────────────────────────────────────┘ │ │ │ │ │ │ │ ▼ │ │ │ Ch. 3 ──▶ Response ──▶ Ch. 4 │ │ │ (Dirty) Validator (Clean) │ │ │ │ │ │ │ ▼ │ │ ◀──────────────────────────── KC Frontend │ │ │ │ ════════════════════════════════════════════════════════════════════════ │ │ Channels: DirectMessageTransport (mini) or NATS/Valkey (small/full) │ └──────────────────────────────────────────────────────────────────────────────┘
Ready to Protect Your Keycloak?
Contact us for a demo and personal consultation.