An SSO Architecture Isn't a Diagram. It's a Fortress of Trust.
Q: "Design a highly-available, on-premise SSO architecture. Explain the traffic flow for both internal and external users."
Why this matters: This is a test of your ability to think in layers. They don't want a list of servers; they want a philosophy of security and resilience. Can you articulate a system that treats trust not as a binary switch, but as a gradient? Can you design a system where failure is a planned, non-catastrophic event?
Interview frequency: High. A classic system design question for senior roles.
❌ The Death Trap
The candidate starts listing components. "First, the user hits a DNS. Then a load balancer. Then an Apache server..." It's a dry, joyless recitation of a network diagram. It's technically correct but demonstrates zero architectural intuition or strategic thinking.
"This approach is all components, no concept. It's like describing a castle by listing its stones. You've missed the entire point of walls, moats, and gatehouses."
🔄 The Reframe
What they're really asking: "How do you build a system that can survive both a hostile attack and its own internal failures, while treating users differently based on their context and level of trust?"
This reveals if you think in first principles: Defense in Depth, High Availability, and Differentiated Trust. A strong answer is a story about managing risk and building resilience, where technology is just the implementation detail of a much deeper philosophy.
🧠 The Mental Model: The Fortress of Trust
A modern SSO architecture is a medieval fortress. It has concentric rings of security. The deeper you go, the more trust is required. We don't just build one wall; we build layers.
The Outer Wall (The DMZ)
This is your first line of defense against the untrusted internet. It’s designed to be attacked. Here, we place sacrificial components like reverse proxies. Their job is to absorb the initial assault and filter traffic before it gets anywhere near the crown jewels.
The Inner Sanctum (The Private Network)
This is where the king lives—your core authentication service (PingFederate). This layer is never, ever directly exposed to the outside world. To get here, you must have passed through the outer wall and been deemed worthy.
The Two Castles (High Availability)
A wise king doesn't build just one castle. He builds two, in different regions, connected by scouts. If one castle falls under siege or suffers a plague (a data center outage), the kingdom's operations seamlessly shift to the other. The kingdom remains secure and operational.
✅ The Answer
"I approach this by designing a 'Fortress of Trust.' The core principle is that we treat users differently based on where they come from. A request from the public internet is fundamentally untrusted, while a request from our internal corporate network is already trusted to a degree. The architecture must reflect this."
The Journey of an External User (The Foreign Visitor)
An external user is an unknown quantity. We must guide them through every layer of our defense.
1. The Scouts (Global Traffic Manager): The user's request first hits a service like Akamai GTM. These are our scouts. They look at the visitor's location and direct them to the nearest, healthiest fortress (our data centers in, say, Chennai or Bangalore). This is the first step in ensuring low latency and high availability.
2. The Outer Wall (Reverse Proxies): The request then arrives at the fortress's outer wall. This is a fleet of hardened Apache reverse proxies sitting behind an External Load Balancer. Their only job is to terminate the initial TLS connection and pass validated requests inward. We never expose our core logic here. If this wall is breached, the inner sanctum remains secure.
3. The Inner Gatehouse (Internal Load Balancer): Having passed the outer wall, the request arrives at the inner gate. This is our Internal Load Balancer (F5). It manages traffic within the trusted private network.
4. The Throne Room (PingFederate Engines): Finally, the request reaches the PingFederate engine nodes. This is our throne room, the core of our authentication logic. It's here that PingFederate consults the royal archives (Active Directory), checks for special permissions (Databases), and enforces multi-factor decrees (MFA Providers) to make an authentication decision.
The Journey of an Internal User (The Trusted Citizen)
An employee on the corporate network is already inside the fortress walls. Their journey is simpler and more privileged.
Their request starts at a Private DNS. Because they are on a trusted network, they get to bypass the outer wall entirely. Their request is routed directly to the Inner Gatehouse (the Internal Load Balancer) and then straight to the Throne Room for authentication.
This differentiated path is critical. It provides a seamless, low-friction experience for trusted users while maintaining a rigorous security posture for untrusted traffic. The architecture itself enforces our trust policy."
🎯 The Memorable Hook
"A great security architecture isn't a wall; it's a series of airlocks. Each one validates your identity before letting you proceed, ensuring that a breach at the perimeter doesn't compromise the core."
This analogy demonstrates a sophisticated understanding of security. It moves beyond the simplistic idea of a single barrier and shows you think in terms of compartmentalization and containment, which are senior-level architectural concepts.
Launch your Graphy