Application Security Architecture

Introducing Zoe Chen

🔧 From this module onward, you’ll meet Zoe Chen — DevSecOps Lead at Apex Digital, a 2,000-person SaaS company that’s cloud-native and AI-first. Zoe’s world is microservices, CI/CD pipelines, container orchestration, and AI workloads. Where Elena thinks about enterprise governance and Ingrid thinks about financial compliance, Zoe thinks about developer velocity and security automation. She believes security that slows developers down will be bypassed — so she designs security that’s invisible to the development team.

Zoe’s cast includes her manager David Park (VP of Engineering) and her counterpart Nina Okafor (Platform Engineering Lead).

---

Identity-First Application Security

The most important principle in modern application security: applications are identities. Every application, service, function, and container should authenticate to other resources using an identity — not a hardcoded password, connection string, or API key.

The Three Application Identity Options

Application Identity Options

	Managed Identity	Service Principal	Workload Identity Federation
What is it?	Azure-managed identity attached to a resource (VM, App Service, Function, etc.)	Entra ID application registration with a client secret or certificate	External identity (GitHub Actions, AWS, GCP) trusted via federation — no secrets exchanged
Credentials to manage?	None — Azure handles token issuance and rotation automatically	Yes — client secret (expires) or certificate (expires). You must rotate.	None — uses OIDC tokens from the external identity provider
Best for	Azure-hosted workloads accessing Azure resources (Key Vault, SQL, Storage, etc.)	Multi-tenant apps, apps needing specific API permissions, legacy integrations	CI/CD pipelines (GitHub Actions, GitLab), cross-cloud workloads (AWS/GCP accessing Azure)
Security risk	Lowest — no credentials exist to leak or steal	Medium — secrets can leak in code, logs, or config files. Expiry helps but doesn't prevent leaks before expiry.	Low — no secrets stored anywhere. Federation trust is scoped to specific issuers and subjects.
Scope of use	Azure resources only (cannot federate to external services)	Any resource that accepts Entra tokens	Any external identity provider that supports OIDC

The Architect’s Decision Framework

The security architect designs the application identity strategy:

1. Default to managed identities for all Azure-hosted workloads. System-assigned for single-purpose resources, user-assigned when multiple resources share an identity.
2. Use workload identity federation for CI/CD pipelines and cross-cloud access. Never store Azure credentials in GitHub Actions secrets when federation is available.
3. Use service principals only when required — multi-tenant applications, legacy systems that can’t use managed identities, or applications needing specific Entra ID permissions.
4. Eliminate all hardcoded credentials — connection strings in app settings, API keys in source code, shared passwords in configuration files.

🎯 Exam Tip: Managed Identity vs Service Principal

SC-100 frequently tests whether you choose managed identity or service principal for a given scenario. The rule is simple: if the workload runs on Azure and accesses Azure resources, managed identity wins every time. Service principals are only preferred when you need app registrations for multi-tenant scenarios or need to grant specific Microsoft Graph permissions. If the question mentions GitHub Actions or AWS, think workload identity federation.

---

Entra Application Proxy

Application Proxy solves a specific problem: how do you provide Zero Trust access to on-premises web applications without a VPN?

How Application Proxy Works

1. User navigates to an external URL (e.g., https://crm.contoso.com)
2. Entra ID authenticates the user and evaluates Conditional Access policies
3. The request is routed to a lightweight connector installed on-premises
4. The connector forwards the request to the internal application (e.g., http://internalcrm:8080)
5. The response flows back through the connector to the user

The application never needs to be exposed to the internet. No inbound firewall ports. No VPN. The connector makes outbound connections only.

Architecture Decisions for Application Proxy

• Connector placement: Install in the same network segment as the target application. Use connector groups to route traffic to specific apps via specific connectors.
• Authentication: Pre-authentication happens at Entra ID (user proves identity before reaching the app). The app can use Kerberos Constrained Delegation, header-based auth, or SAML for back-end SSO.
• Conditional Access: Full Conditional Access applies — require MFA, compliant device, specific location. This gives legacy apps Zero Trust protection they weren’t designed for.
• High availability: Deploy at least two connectors per connector group. Connectors are stateless and auto-update.

☁️ Scenario: Rajan’s Legacy CRM Recommendation

Rajan at Skyline Security Consulting is advising a client whose sales team needs remote access to an on-premises CRM system built in 2015. The CRM has no modern authentication — it uses Windows Integrated Authentication (Kerberos). Currently, sales reps connect via VPN, which is slow and gives them network-level access to the entire corporate network.

Rajan’s recommendation:

Replace VPN access with Application Proxy:

• Deploy two connectors on domain-joined servers in the CRM’s network segment
• Configure Kerberos Constrained Delegation for SSO (the connector obtains a Kerberos ticket on behalf of the user)
• Apply Conditional Access: require MFA + compliant device + sales team group membership
• The CRM remains completely internal — no internet exposure, no inbound firewall rules

Why this beats VPN:

• Users authenticate to Entra ID first, not to the network. Zero Trust principle.
• VPN gave network access to everything. Application Proxy gives access to one application.
• Conditional Access wasn’t possible with VPN — now every access attempt is evaluated against policy.

Priya Anand (Rajan’s junior architect) asks: “What about performance?” Rajan explains that the connector-to-cloud communication uses persistent outbound connections, so latency is typically comparable to VPN. For latency-sensitive deployments, connectors should be placed close to the application server.

---

API Security Architecture

APIs are the backbone of modern applications. Every microservice, mobile app, and third-party integration communicates through APIs. Securing them requires:

OAuth 2.0 Flow Selection

The architect selects the appropriate OAuth flow based on the client type:

• Authorization Code + PKCE — Web applications and single-page apps (SPAs). The most secure flow for user-interactive scenarios.
• Client Credentials — Service-to-service communication where no user is involved. The application authenticates as itself.
• On-Behalf-Of (OBO) — A middle-tier API needs to call a downstream API on behalf of the user who called it. Preserves user context through the chain.
• Device Code — Devices without a browser (IoT devices, CLI tools). User authenticates on a separate device.

API Management as Security Gateway

Azure API Management sits in front of your APIs and enforces security policies:

• Token validation — Verify JWT tokens before the request reaches the back-end API
• Rate limiting — Prevent abuse and denial-of-service
• IP filtering — Restrict access to known IP ranges
• Request/response transformation — Strip sensitive headers, mask data
• Subscription keys — Additional layer of access control beyond OAuth tokens
• Certificate validation — Mutual TLS for high-security API access

The architect designs API Management as a centralised policy enforcement point. Back-end APIs should never be directly accessible — all traffic flows through the gateway.

---

Container Security Architecture

Containers introduce unique security challenges because they’re ephemeral, share a host kernel, and pull images from external registries.

Container Security Layers

1. Image security — Scan images for vulnerabilities before deployment. Use Azure Container Registry with Defender for Containers to block vulnerable images from being deployed.
2. Registry security — Private registries only. No pulling from Docker Hub in production. Enable content trust for image signing.
3. Runtime security — Defender for Containers monitors running containers for suspicious behaviour (reverse shells, cryptocurrency mining, privilege escalation).
4. Network security — Kubernetes network policies restrict pod-to-pod communication. Default deny, allow only required traffic.
5. Host security — The underlying nodes (AKS node pools) need OS hardening, automatic patching, and monitoring.

AKS Security Architecture

For Azure Kubernetes Service (AKS), the architect designs:

• Entra ID integration — Kubernetes RBAC backed by Entra ID groups. No local admin accounts.
• Azure Policy for AKS — Enforce pod security standards (no privileged containers, no root, required resource limits)
• Private clusters — AKS API server accessible only through private endpoints, not the public internet
• Managed identity for pods — Workload identity for AKS lets pods authenticate to Azure resources using federated identity — no secrets mounted in pods

🔧 Scenario: Zoe’s Microservice Identity Design

Zoe’s team at Apex Digital runs 40 microservices on AKS. Each service needs to access different Azure resources — one reads from Cosmos DB, another writes to Storage, a third calls Azure OpenAI. Previously, the team stored connection strings in Kubernetes secrets, but Zoe knows this is a credential management nightmare.

Zoe designs a managed identity architecture:

For each microservice:

1. Create a user-assigned managed identity in Azure
2. Configure workload identity federation between the AKS cluster and the managed identity
3. Annotate the Kubernetes service account to use the federated identity
4. Grant the managed identity RBAC permissions on only the Azure resources that microservice needs

Result:

• No credentials in code, config, or Kubernetes secrets
• Each microservice has least-privilege access to only its required resources
• If a container is compromised, the attacker gets access to only that microservice’s permissions, not a shared credential that unlocks everything
• Identity rotation is automatic — no scheduled secret rotation pipelines

David Park asks: “Is this more complex than just using connection strings?” Zoe responds: “The initial setup is more work. But we eliminate an entire class of incidents — leaked credentials, expired secrets causing outages, overly broad shared accounts. The complexity moves from operations (rotating secrets) to architecture (designing identity relationships), and architecture is a one-time cost.”

---

Azure Key Vault Integration

Even with managed identities, some secrets still exist — third-party API keys, certificates for mutual TLS, encryption keys for customer data. Key Vault provides centralised, audited, access-controlled storage.

Key Vault Architecture Decisions

• Vault per environment — Separate vaults for dev, staging, and production. Prevents accidental cross-environment access.
• RBAC vs access policies — RBAC (recommended) provides fine-grained permissions at the secret, key, or certificate level. Access policies are legacy and grant broader access.
• Soft delete and purge protection — Always enable. Prevents accidental or malicious deletion of cryptographic material.
• Private endpoints — Key Vault should only be accessible from your virtual network, not the public internet.
• Certificate management — Key Vault can auto-renew certificates from integrated CAs (DigiCert, GlobalSign). Eliminates manual certificate rotation.

Knowledge Check

Zoe's team at Apex Digital runs microservices on AKS that need to access Azure Cosmos DB, Azure Storage, and Azure OpenAI. Currently, connection strings are stored in Kubernetes secrets. What should Zoe implement to eliminate stored credentials?

AA. Move connection strings from Kubernetes secrets to Azure Key Vault and mount them as volumesBB. Configure workload identity federation with user-assigned managed identities for each microserviceCC. Create a single service principal with access to all three Azure resources and use a client certificateDD. Use AKS pod-managed identity (aad-pod-identity v1) with system-assigned identities

Check Answer

Knowledge Check

A client's sales team currently uses VPN to access an on-premises CRM application that uses Windows Integrated Authentication. The CRM cannot be modified to support modern authentication. The client wants to eliminate VPN dependency and apply Zero Trust principles. What should the architect recommend?

AA. Migrate the CRM to Azure App Service and enable Entra ID authenticationBB. Deploy Entra Application Proxy with Kerberos Constrained Delegation and Conditional AccessCC. Configure Azure Front Door with a site-to-site VPN back-end to add WAF protectionDD. Implement a third-party reverse proxy in the DMZ with SAML authentication

Check Answer

Knowledge Check

An architect is designing API security for a web application that calls a middle-tier API, which then calls a downstream Azure resource API on behalf of the signed-in user. Which OAuth 2.0 flow should the middle-tier API use to call the downstream API?

AA. Client Credentials flowBB. Authorization Code flow with PKCECC. On-Behalf-Of (OBO) flowDD. Device Code flow

Check Answer

---

Knowledge Check

Question

What is the key architectural advantage of managed identities over service principals?

Click or press Enter to reveal answer

Answer

Managed identities eliminate credential management entirely. Azure handles token issuance and rotation automatically — there are no secrets, certificates, or passwords to store, rotate, or accidentally leak. Service principals require you to manage client secrets (which expire and can leak) or certificates (which expire and need rotation). For Azure-hosted workloads accessing Azure resources, managed identities remove an entire category of operational risk.

Click to flip back

Question

How does Entra Application Proxy enable Zero Trust for legacy applications?

Click or press Enter to reveal answer

Answer

Application Proxy pre-authenticates users at Entra ID before they reach the application. The on-premises app is never exposed to the internet — the lightweight connector makes outbound-only connections. Full Conditional Access applies (MFA, device compliance, location). The app doesn't need to support modern authentication — the connector handles SSO via KCD, headers, or SAML. This gives legacy apps Zero Trust protection they weren't designed for, without modifying the application.

Click to flip back

Question

What is workload identity federation and when does an architect choose it?

Click or press Enter to reveal answer

Answer

Workload identity federation lets external identity providers (GitHub Actions, AWS, GCP, other OIDC providers) access Azure resources without storing Azure credentials. The external workload presents its own OIDC token, and Entra ID trusts it based on a configured federation relationship. The architect chooses it for CI/CD pipelines (no Azure secrets in GitHub), cross-cloud access (AWS workloads accessing Azure), and AKS pods (workload identity for Kubernetes).

Click to flip back

Question

Why should Azure API Management be the only entry point to back-end APIs?

Click or press Enter to reveal answer

Answer

API Management acts as a centralised security policy enforcement point. It validates OAuth tokens before requests reach back-end services, enforces rate limiting, filters by IP, transforms requests to strip sensitive data, and provides a single audit point. If back-end APIs are directly accessible, each API must implement its own security — leading to inconsistent enforcement, missed validations, and a larger attack surface.

Click to flip back

---

🎬 Video coming soon

---

Summary

Application security architecture is identity-first: managed identities for Azure workloads, workload identity federation for external pipelines, and service principals only when required. Application Proxy extends Zero Trust to legacy on-premises apps. API Management provides centralised security policy enforcement. Container security requires scanning at build, runtime monitoring, and network microsegmentation. Key Vault centralises secret and certificate management. The architect’s goal is to eliminate credentials from code and design identity relationships that enforce least privilege at every layer.

Next module: We build on application identity to explore DevSecOps — how security integrates into every stage of the development lifecycle.