Federate First,
Migrate When Ready
Your enterprise IDP doesn't have to change on day one. The gateway layer acts as a Service Provider, federating with whatever identity system you already have — while backends receive identical headers they've always expected. No re-deployment. No re-architecture. Just federation.
Watch for the header injection step. After OPA allows the request,
the gateway maps JWT claims directly to
iv-user and
iv-groups headers
before forwarding to the backend. The backend has no idea the proxy changed.
That's the entire migration strategy: change the front, preserve the interface.
Enterprise IDP Federation Flow
Step through SP/IDP federation: the gateway validates a token issued by your SP, which in turn trusted your enterprise IDP — without touching a single backend.
What each layer does
| Layer | System | Responsibility | Replaces |
|---|---|---|---|
| Gateway | APISIX | Intercept, validate JWT, enforce, inject headers | Reverse proxy + session manager |
| SP | Keycloak (Realm 1) | Federate with enterprise IDP, issue tokens APISIX trusts | Auth orchestration layer |
| IDP | Enterprise IDP (Realm 2) | Authenticate users, validate against directory | Identity provider (unchanged in Phase 1) |
| Policy | OPA | Evaluate endpoint ACL rules via REGO | Protected object space / ACL rules |
| Backend | Your apps | Business logic — reads headers, no auth code | Unchanged ✓ |