Beyond the Castle Walls: An ADFS to Zero-Trust Migration Story

Senior/Staff Engineer Asked at: Microsoft, Large Enterprises, Banks

Q: I see you have experience with security enhancements. Could you tell me about the project where you migrated from ADFS to SAML and OAuth2.0?

Why this matters: This is a senior-level question about strategic modernization. They're testing your ability to lead a high-stakes migration that impacts every user and service. Can you articulate the deep architectural shift from a legacy, perimeter-based security model to a modern, identity-based one?

Interview frequency: High for architects and senior engineers in enterprise environments.

❌ The Death Trap

Candidates often get lost in a "word salad" of acronyms, describing the technical steps without explaining the fundamental shift in security philosophy.

"We decommissioned our ADFS farm and configured Azure AD as our new identity provider. We updated our relying party trusts to use SAML 2.0 endpoints for SSO. For our APIs, we registered them as applications in Azure AD and implemented the OAuth2.0 client credentials flow to secure them."

This answer is technically precise but strategically empty. It tells the interviewer you can follow a technical manual, but not that you understand the profound business and security implications of your work.

🔄 The Reframe

What they're really asking: "Can you explain why the old model of 'trust but verify' inside the corporate network is broken? How did you lead your organization towards a 'never trust, always verify' Zero-Trust model, and what concrete technical steps did you take to get there?"

This reframes the project from a simple technology swap to a fundamental change in the company's security posture, driven by business needs like cloud adoption and API-first development.

🧠 The Mental Model

The "Castle and Moat vs. Modern City" model. Our security was evolving from a medieval fortress to a bustling, modern metropolis.

1. The Old World (ADFS Castle): Our on-premise network was a castle, and ADFS was the single, heavily fortified drawbridge. If you were inside the walls, you were trusted. If you were outside, you were not. This model was brittle, hard to scale, and useless for cloud services or external partners.

2. The New World (The API City): The modern cloud is a city with no walls. The perimeter is gone. Every building (API, service, app) must be its own fortress and check ID at the door. Trust is never assumed based on location.

3. SAML (The Universal ID Card): To navigate this city, our users needed a modern, universal ID card. SAML (via Azure AD) became that card. It's a trusted, verifiable credential that lets our users access any authorized web application (building) without needing a separate key for each one.

4. OAuth2.0 (The Secure Courier's Pass): But what about services talking to each other? A Windows Service needing data from a web API is like a secure courier. OAuth2.0 provides a specific, time-limited, and audience-restricted pass (a JWT bearer token) for that courier to access one specific building for one specific purpose.

📖 The War Story

Situation: "Our company had a decade-old, on-premise infrastructure. At its heart was a large, complex Active Directory Federation Services (ADFS) farm. It was the gatekeeper to everything."

Challenge: "The business was trying to move to the cloud, build a mobile app, and create a partner API ecosystem. Our ADFS 'castle' was a direct blocker. It was a single point of failure, expensive to maintain, and it spoke a language that modern cloud services didn't understand. Simple tasks like integrating a new SaaS tool took months."

Stakes: "This wasn't just a technical debt problem; it was a business growth problem. Our security model was actively preventing us from building the products our customers were demanding. The risk of maintaining the aging ADFS farm was also becoming untenable."

✅ The Answer

My Thinking Process:

"My thesis was that our security model needed to shift from being network-centric to identity-centric. The fundamental unit of trust should no longer be the server's IP address, but a verifiable, token-based claim about a user or a service. This is the core of a Zero-Trust architecture."

What I Did: A Phased Modernization

Phase 1: Liberate the Humans (SAML Migration): I started with user-facing applications. I led the project to configure Azure AD as our primary identity provider and migrated our top 10 enterprise web apps from ADFS to use SAML 2.0 against Azure AD. This was a series of low-risk, high-impact wins that built momentum and allowed us to start scaling down the ADFS farm.

Phase 2: Secure the Machines (OAuth2.0 for Services): The more complex challenge was our backend. We had dozens of legacy Windows Services and APIs that used brittle methods like service accounts or IP whitelisting to communicate. This was our biggest internal security risk. I architected the move to OAuth2.0's Client Credentials flow. Each service was registered as an application in Azure AD with its own client ID and secret. Before calling another service, it would first authenticate itself to Azure AD and receive a short-lived JWT bearer token."

// Simplified .NET Client Concept
private async Task<string> GetAccessTokenAsync()
{
    var client = new HttpClient();
    var request = new HttpRequestMessage(HttpMethod.Post, "https://login.microsoftonline.com/...");
    
    var body = new Dictionary<string, string>
    {
        { "grant_type", "client_credentials" },
        { "client_id", _clientId },
        { "client_secret", _clientSecret },
        { "scope", "https://api.mycompany.com/.default" }
    };
    request.Content = new FormUrlEncodedContent(body);

    var response = await client.SendAsync(request);
    // ... parse token from response
    return accessToken;
}

// Calling the protected API
var token = await GetAccessTokenAsync();
_apiClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", token);
var data = await _apiClient.GetAsync("/api/data");
            

The Outcome:

"The results were transformative. We decommissioned our entire ADFS farm, saving over $80k annually in hardware and licensing. But the real win wasn't cost. Our security posture improved dramatically; we now had auditable, short-lived, and narrowly-scoped credentials for all machine-to-machine communication. This unlocked our business goals: we were finally able to securely expose our new partner APIs and build a native mobile app, both of which were impossible under the old model."

What I Learned:

"I learned that modern security architecture is an enabler, not a blocker. By moving away from our legacy 'castle,' we didn't just become more secure; we became more agile. The project taught me that the hardest part of a security migration isn't the technology, it's articulating the vision and leading the cultural shift from a perimeter-based mindset to a Zero-Trust one."

🎯 The Memorable Hook

"We weren't just changing a protocol; we were changing our entire philosophy of trust. We moved from trusting a location—the internal network—to trusting a cryptographically verifiable proof of identity. That shift is the foundation of all modern cloud security."

This connects your technical work to a profound, first-principles shift in security, demonstrating deep strategic insight.

💭 Innevitable Follow-ups

Q: "What was the most difficult legacy application to migrate, and how did you handle it?"

Be ready: "We had an old internal portal that didn't support any modern protocols. For that, we used Azure AD Application Proxy. It acted as a reverse proxy and a security bridge, handling the modern authentication with Azure AD on the outside and presenting a simpler authentication mechanism to the legacy app on the inside. It was a pragmatic stopgap that allowed us to decommission ADFS without rewriting that entire application."

Q: "You mentioned the Client Credentials flow. When would you use a different OAuth2.0 flow, like Authorization Code?"

Be ready: "Client Credentials is for trusted, server-to-server communication where there's no human user involved. We'd use the Authorization Code flow for third-party applications or our own web apps where a human user needs to delegate permission. For example, if we built a 'Connect your Google Calendar' feature, that would use Authorization Code to get the user's explicit consent."