On this page
Context and Problem Statement
A federated authentication solution is required across clusters and hosted services to simplify smart access operations. The platform baseline already assumes keycloak; this ADR decides the deployment architecture and resilience model.
Scope boundary: this ADR decides SSO service topology and failover behavior; broader IAM role/realm and integration architecture is handled in ADR-015.
Decision Drivers
- Resilience to single-site disruptions.
- Support for approximately 50,000 users (internal and external).
- automation-friendly deployment and operations.
- Compliance with MFA, audit logging, and cryptography requirements.
Considered Options
- Stand-alone Keycloak clusters per datacenter without cross-site replication.
- Replicated Keycloak clusters with single-active failover and database replication.
Decision Outcome
Decision remains draft. keycloak remains the baseline smart access component (see ADR-005), while deployment topology is under evaluation.
Next Decision Trigger
- Decision owner: Platform Architecture with Security Architecture review.
- Promote to
acceptedwhen failover test evidence, database replication posture, and operational runbooks are approved. - If replicated topology cannot meet service objectives, publish fallback constraints and revised option ranking before 2026-03-15.
Pros and Cons of the Options
Option 1 – Stand-alone clusters per datacenter
Pros
- Simpler deployment and operational separation between sites.
Cons
- No cross-site state replication; failover requires client reconfiguration.
Option 2 – Replicated clusters with single-active failover
Pros
- Controlled failover with shared state across sites.
- Aligns with resilience requirements for identity and access management.
Cons
- More complex replication and load-balancing configuration.
- Higher operational overhead for database and cache replication.