Azure Identity & Access Management Domain

Identity is the foundational security plane in Azure. Every operation—from a user signing in to a container calling a database—depends on a verified identity and explicitly granted permissions. This domain page explains identity as an architectural concern, not a product checklist. It connects core concepts, design decisions, and real-world patterns you will need for enterprise cloud architecture, security engineering, and AI‑enabled systems.

1. Overview

#

What Identity Means in Cloud Architecture

#

In cloud computing, an identity is a uniquely identifiable security principal that can be authenticated and authorized to access resources. It can represent:

• A human user (employee, partner, customer)
• A workload (virtual machine, container, function, application service)
• A device (managed endpoint, IoT edge)
• An automated process or AI agent

Identity is the control plane for every operation. Before any data plane call, management operation, or API invocation, the cloud control plane resolves “who is calling” and “what are they allowed to do.”

Why Identity Is the First Layer of Azure Architecture

#

In traditional on-premises architectures, the network perimeter (firewalls, VPNs, VLANs) acted as the primary security boundary. In Azure, resources can be globally distributed, accessed over the public internet, and composed from multiple services. The network alone is no longer a sufficient trust boundary. Identity replaces the perimeter.

Every Azure service—compute, storage, networking, AI—integrates with Microsoft Entra ID for authentication and with Azure RBAC for authorization. Designing identity correctly from the start prevents privilege escalation, data leakage, and lateral movement. It is the first architectural decision that shapes all other security, compliance, and operational patterns.

2. Core Concepts

#

Authentication vs Authorization

#

• Authentication (AuthN) proves the identity of a security principal. In Azure this is handled by Microsoft Entra ID, using protocols like OpenID Connect, SAML, and certificate-based authentication. It answers: Who are you?
• Authorization (AuthZ) determines what an authenticated principal is permitted to do. In Azure this is primarily Role-Based Access Control (RBAC), supplemented by attribute-based controls (ABAC) for specific data plane operations. It answers: What are you allowed to do?

These are distinct steps. A service like Azure OpenAI first authenticates the caller (Entra ID token), then authorizes the requested operation against the Azure resource or against data content.

Identity Lifecycle

#

Identities follow a lifecycle: provision → configure → use → monitor → deprovision. In cloud architecture, lifecycle automation is critical:

• Joiners/movers/leavers must propagate to Entra ID automatically from HR systems.
• Workload identities (service principals, managed identities) are created and revoked with infrastructure as code.
• Access reviews and Privileged Identity Management enforce just‑in‑time and time-bound access.

A well‑architected system treats identity lifecycle as a continuous process integrated into CI/CD, HR feeds, and governance tooling.

Least Privilege Principle

#

Every identity—human or workload—should receive only the permissions necessary to perform its intended function, and no more. This principle:

• Reduces blast radius of compromised credentials.
• Simplifies compliance auditing.
• Forces explicit role decomposition, which improves security posture.

In practice, least privilege means using custom RBAC roles, scoping assignments to resource groups or specific resources, and avoiding built‑in Owner/Contributor roles for day‑to‑day operations.

Zero Trust Model

#

Zero Trust is a security architecture principle that assumes breach and verifies explicitly per request. Its three core tenets:

1. Verify explicitly — always authenticate and authorize based on all available data points (user identity, device health, location, anomaly detection).
2. Use least privileged access — just‑in‑time and just‑enough‑access.
3. Assume breach — segment access, encrypt everywhere, monitor continuously.

In Azure, identity is the center of Zero Trust. Conditional Access policies evaluate signals at every authentication attempt, and RBAC ensures fine-grained authorization on each API call, not just at perimeter boundaries.

3. Azure Identity Services Mapping

#

Microsoft Entra ID

#

The cloud-native identity provider (formerly Azure Active Directory). It serves as the directory for users, groups, devices, and application registrations. It issues security tokens (JWT) that Azure Resource Manager and most Azure services trust. Entra ID supports B2B collaboration, B2C for customer identities, and multi‑tenant architectures. Every Azure subscription trusts exactly one Entra tenant—this trust relationship is the root of the Azure identity architecture.

Role-Based Access Control (RBAC)

#

Azure RBAC is an authorization system built on Azure Resource Manager that assigns roles to security principals at specific scopes (management group, subscription, resource group, resource). Roles define a set of permissions (actions, notActions, dataActions). It answers: What operations can this identity perform on which resources?

RBAC is applied for both management plane (create VM) and, where configured, data plane (read a blob, query a Key Vault secret) operations.

Managed Identity

#

Managed identities are Entra ID identities tied directly to an Azure resource, such as a VM, App Service, or AKS pod (via workload identity). Azure automatically handles credential lifecycle—no secrets to store. Two types:

• System-assigned: tied 1:1 to a resource lifetime.
• User-assigned: reusable across multiple resources.

Managed identities are the default choice for workload authentication because they eliminate secret management and support credential rotation transparently.

Service Principal

#

A service principal is the instantiation of an Entra ID application registration in a tenant. It represents an application or automation tool that needs to authenticate. Service principals can use client secrets, certificates, or federated credentials. They are required when workloads run outside Azure (e.g., GitHub Actions, on-premises systems) or when shared across subscriptions.

Conditional Access

#

Conditional Access is the policy engine in Entra ID that enforces Zero Trust at the authentication step. Policies evaluate signals—user/group, device platform, location (IP), sign‑in risk, application—and enforce controls like MFA, device compliance, or block access. This is the primary mechanism to move from static network-based rules to dynamic, risk-based access.

Privileged Identity Management (PIM)

#

PIM provides just‑in‑time privileged role activation in Microsoft Entra ID and Azure resources. Instead of permanent high-privilege assignments, users are eligible to activate roles for a limited time, with approval, justification, and full audit trail. PIM is a cornerstone of identity governance and operational security for administrative access.

External Identities

#

Entra External ID enables secure collaboration with partners, vendors, and customers. Using B2B, external users authenticate with their own identity provider or receive guest accounts in your tenant. B2C allows customer-facing applications to use branded, custom authentication flows. Architecturally, this enables a unified identity plane while isolating directory boundaries.

4. Architecture Role of Identity

#

Compute Resources (VMs, AKS, Functions)

#

• VMs: system-assigned managed identity authenticates to Azure Key Vault, storage, or Azure SQL without credentials in code. User-assigned identity provides consistent identity for scale sets.
• AKS: pod identities (workload identity) allow individual pods to assume unique identities without node‑wide access. Integration with Entra Workload ID enables fine-grained service-to-service calls.
• Azure Functions: managed identity or service principal for triggers and bindings. Identity is configured at the function app level, governing all outbound authenticated calls.

Storage Access Control

#

Azure Storage supports two authorization layers:

• Management plane: RBAC controls who can create or modify storage accounts.
• Data plane: RBAC (via built‑in data roles) and ABAC (attribute-based rules via Azure Storage data actions) control access to blobs, queues, tables. Managed identity + RBAC removes the need for storage account keys.

Networking Security Boundaries

#

Identity integrates with network controls to create layered security:

• Azure Private Link uses managed identity for authorizing private endpoint connections to PaaS services.
• Just‑In‑Time VM access leverages role‑based assignments in Microsoft Defender for Cloud.
• Conditional Access can enforce that access to Azure management endpoints only occurs from compliant, managed devices, reinforcing network micro-segmentation with identity.

API Authentication

#

Azure API Management, App Service, and Functions consume Entra ID tokens for B2B and service‑to‑service calls. OAuth 2.0 client credentials grant enables workload identities to call APIs. The architecture pattern: every API endpoint validates the JWT, extracts the oid or sub claim, and uses that identity in downstream authorization.

Data Platforms (Synapse, Databricks)

#

• Azure Synapse Analytics: managed identity authenticates to Data Lake Storage. RBAC and ACLs combine for workspace and data access. The Synapse pipeline runs under an identity scoped to the pipeline.
• Azure Databricks: service principal or managed identity (through Unity Catalog) is used for accessing storage and running jobs. Unity Catalog enforces fine-grained access control on tables, rows, and columns using identity-aware constructs.

AI/LLM Systems (Azure OpenAI, Tool Authorization, RAG Access Control)

#

AI systems amplify the importance of identity. When an LLM calls a tool, queries a knowledge base, or writes data, it acts under some identity.

• Azure OpenAI: authenticates via API key or Entra ID (managed identity). For enterprise deployments, Entra ID is preferred to apply RBAC, Conditional Access, and network restrictions to model inference endpoints.
• Tool‑calling authorization: In AI orchestration (e.g., Semantic Kernel, LangChain), the agent’s tool must execute under a scoped identity. The architecture must ensure the AI‑chosen tool call inherits the user’s authorization context, not the agent’s broad permissions. This is often implemented via on‑behalf‑of (OBO) flows or token‑exchange patterns.
• RAG access control: When retrieving documents from a vector store or Azure AI Search, identity‑aware filtering ensures the LLM only surfaces content the calling user/principal is permitted to see. This prevents cross‑tenant data leakage in multi‑user AI applications.

Agent Systems (GH‑600 Style Autonomous Agents and Tool Permissions)

#

Autonomous agents (e.g., GitHub Copilot agents, custom multi‑step reasoners) introduce complex identity chains. An agent may:

• Plan a sequence of tool calls.
• Access APIs, databases, and code repositories.
• Execute on behalf of a user, with delegation.

The identity design must:

• Establish agent identity — the agent itself is a workload identity (managed identity or service principal) that proves its origin.
• Act on behalf of a user — use delegated permissions and OBO tokens so the target service can authorize based on the original user.
• Constrain tool permissions — each tool the agent can invoke should have a minimal, immutable scope enforced at the identity layer (RBAC roles, scoped API permissions). This mitigates the risk of prompt injection that could abuse an overly privileged agent.

5. Design Decisions

#

When to Use Managed Identity vs Service Principal

#

Guidance: Use managed identities for all Azure‑hosted workloads. Use service principals only for processes originating outside Azure, cross‑tenant calls, or scenarios requiring interactive consent.

RBAC vs ABAC

#

• RBAC is role-centric: you assign a principal to a role at a scope. It is coarse‑grained and ideal for management operations (create, delete, configure).
• ABAC (Attribute‑Based Access Control) adds conditions on RBAC assignments, currently available for Azure Storage data plane. You can, for example, allow read access only if the blob index tag department=finance matches the user’s department attribute.

Decision: Use RBAC as the primary authorization model. Add ABAC when you need dynamic, context‑driven data‑plane restrictions that cannot be expressed with static roles alone.

Tenant‑Level vs Subscription‑Level Identity Design

#

A tenant is the top‑level identity boundary. Decisions:

• Single tenant for an enterprise simplifies collaboration and identity governance.
• Multi‑tenant architectures may require separate tenants for development/production isolation, or for subsidiaries with different regulatory domains. Azure Lighthouse enables cross‑tenant management without merging identity platforms.
• Subscription design groups resources for billing and management. RBAC assignments can be scoped at subscription or management group level, but the identity source is always the tenant.

Guidance: Start with a single tenant unless legal or organizational constraints require separation. Use management groups and subscription hierarchies to enforce policy and access control, not additional tenants.

Human Identity vs Workload Identity

#

• Human identity: interactive sign‑in, subject to Conditional Access (MFA, location), PIM for privileged roles. Lifecycle tied to HR systems.
• Workload identity: non‑human, no interactive login. Relies on client credentials, managed identity, or federated tokens. Not a member of Conditional Access policies per se, but can be protected via workload identity protection policies (Entra ID Protection).

Architecture principle: Never use a human identity’s credentials for automation. Strict separation ensures auditability and prevents token lifetime issues.

Identity Design for AI Applications and Agents

#

Key design considerations:

• User identity propagation: Every user-facing AI feature must carry the end‑user’s identity through all layers. Implement OBO or token exchange patterns so the LLM, search index, and database all enforce user‑level permissions.
• Agent sandboxing: Agent tools must run with minimal identity, using scoped RBAC roles. For example, an agent that can summarize support tickets should not have delete access to the CRM, even if the agent framework attempts that action.
• Prompt injection defense at the identity layer: Design authorization to be non‑negotiable, independent of the prompt. Even if an attacker crafts a prompt instructing the agent to “reset all passwords,” the underlying identity lacks permission, so the action fails. The identity boundary is the last line of defense.
• Secrets for AI services: Prefer managed identity over API keys for Azure OpenAI and other AI services to allow RBAC, network controls, and rotation.

6. Security & Enterprise Considerations

#

Zero Trust Implementation in Azure

#

Concrete implementation in Azure:

• Verify explicitly: Entra ID Conditional Access evaluates user risk, device compliance, and sign‑in risk before issuing tokens.
• Least privilege per request: Azure RBAC at resource scope; data plane RBAC/ABAC; just‑in‑time PIM for administrative operations.
• Assume breach: Network micro‑segmentation (NSGs, Private Endpoints), encryption at rest and in transit, continuous monitoring via Microsoft Defender for Cloud and Sentinel.

Identity as Perimeter Replacement

#

The security boundary moves from network ACLs to identity‑based access policies. Every service request is authenticated and authorized. This design:

• Enables secure work from any location without VPN.
• Eliminates the notion of a “trusted internal network.”
• Requires robust device health and MFA posture, enforced via Conditional Access.

Conditional Access Policies

#

Effective Conditional Access requires:

• Policy coverage for all cloud apps, including management tools (Azure Portal, CLI, PowerShell).
• Device compliance integration with Intune.
• Risk‑based policies leveraging Entra ID Protection signals.
• Emergency “break‑glass” accounts exempt from policy but monitored.

Enterprise architectures typically define tiers of policies: baseline (MFA for all users), privileged (MFA + compliant device for admins), and restrictive (block legacy authentication, high‑risk sign‑ins).

Identity Governance and Compliance

#

Identity governance in Azure includes:

• Entitlement management: access packages for structured provisioning and periodic reviews.
• Access reviews: automated re‑certification of group memberships and role assignments.
• PIM: just‑in‑time privileged roles with approval workflows and full logging.
• Logs & monitoring: Entra ID sign‑in logs, audit logs, Azure Activity logs, and integration with SIEM/Sentinel.

These capabilities meet regulatory requirements (SOX, HIPAA, PCI) by providing provable access control and audit trails.

AI‑Era Identity Risks

#

AI agents and LLM‑driven applications introduce new attack vectors:

• Prompt injection: an attacker may inject instructions that cause the agent to invoke tools in unintended ways. Identity design must ensure the agent’s tool permissions are scoped so that even a successful injection cannot exceed authority.
• Authorization context confusion: if the agent uses its own broad identity instead of the user’s, a malicious prompt could exfiltrate data the user should not see. The solution is strict user‑identity propagation (OBO) and user‑scoped authorization checks in every backend service.
• Data poisoning via identity misconfiguration: if a vector store or fine‑tuning pipeline uses overly permissive identities, an attacker could corrupt shared data. Resource‑level isolation and managed identity per component are crucial.

Architects must treat the agent’s identity and tool permissions as a hardened security boundary, not an afterthought.

7. Certification Mapping

#

This domain is foundational across multiple Azure and AI certifications. Here’s how the identity topics align:

8. Real‑world Architecture Example

#

Consider a multi‑tier application deployed on Azure that serves an external customer base and provides an AI assistant.

Components:

• Front‑end: Azure App Service (JavaScript) authenticates customer users via Entra External ID (B2C).
• API layer: Azure Functions (backend API) accessed by the front‑end and by a mobile app.
• Data layer: Azure SQL Database and Azure Blob Storage.
• AI services: Azure OpenAI with GPT‑4, Azure AI Search for RAG, and a custom agent orchestrator running in Azure Container Apps.

Identity design:

• Customer users: Authenticate through B2C user flows. The API Functions receive a B2C‑issued JWT and validate it. The sub claim identifies the user for data scoping.
• Front‑end to API: The App Service passes the B2C token to the API, which performs on‑behalf‑of (OBO) exchange to call downstream services as the user.
• API to database: The API Function uses a managed identity (system‑assigned) to authenticate to Azure SQL. It uses row‑level security (RLS) with SESSION_CONTEXT set to the user ID from the token, ensuring the database enforces per‑user isolation even though the workload identity is shared.
• Storage access: The API Function’s managed identity has the “Storage Blob Data Contributor” role scoped to the storage account. When uploading/downloading user files, the application tags blobs with userId, and ABAC conditions ensure the identity can only access blobs where userId matches the current user (attribute passed via OBO token claims).
• AI assistant agent: The agent container has a user‑assigned managed identity. However, when acting on behalf of a user, it obtains an OBO token from the user’s initial token (via a token exchange endpoint) before calling APIs or databases. The agent’s tool definitions are mapped to scoped access: “search_knowledge_base” uses Azure AI Search with search index security filters based on user group claims; “create_ticket” calls the CRM API with the user’s delegated permissions. The agent’s direct identity is never used for user‑specific data operations.
• Zero Trust enforcement: Conditional Access policies require MFA for all B2C users and compliant device for administrative access to Azure resources. The AI agent’s workload identity is protected by Conditional Access for workload identities, blocking requests from unexpected IP ranges.

This architecture demonstrates identity as the unifying security layer: B2C for consumers, managed identity for services, and OBO for user‑context propagation into the AI tier. Every call is authenticated, every permission is scoped, and no secrets are stored in code or configuration.