Skip to content

Commit b961bd2

Browse files
authored
Merge pull request #7491 from jonburchel/2025-10-06-auth-options-foundry
2025 10 06 auth options foundry
2 parents 4d86f1a + 2b3cf5f commit b961bd2

File tree

4 files changed

+182
-0
lines changed

4 files changed

+182
-0
lines changed
Lines changed: 180 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,180 @@
1+
---
2+
title: Authentication and authorization options in Azure AI Foundry
3+
description: Learn the authentication and authorization options for Azure AI Foundry including API keys, Microsoft Entra ID, managed identities, and common RBAC scenarios.
4+
ms.author: jburchel
5+
author: jonburchel
6+
ms.reviewer: meerakurup
7+
ms.date: 09/25/2025
8+
ms.topic: concept-article
9+
ms.service: azure-ai-foundry
10+
ai.usage: ai-assisted
11+
#customer intent: As a platform admin, I want to choose and implement the right authentication approach for Azure AI Foundry so my teams are secure and productive.
12+
---
13+
14+
# Authentication and authorization options in Azure AI Foundry
15+
16+
Azure AI Foundry supports multiple authentication approaches to balance security, operational simplicity, and speed. This article explains the control plane and data plane model, compares API key and Microsoft Entra ID (formerly Azure AD) authentication, maps identities to roles, and describes common least privilege scenarios. Use this article with:
17+
18+
- [Role-based access control for Azure AI Foundry](rbac-azure-ai-foundry.md)
19+
- [Configure keyless authentication with Microsoft Entra ID](../foundry-models/how-to/configure-entra-id.md)
20+
- [Rotate API access keys](../../ai-services/rotate-keys.md?context=/azure/ai-foundry/context/context)
21+
- [Azure built-in roles (AI + machine learning)](/azure/role-based-access-control/built-in-roles#ai-+-machine-learning)
22+
23+
> [!IMPORTANT]
24+
> Use Microsoft Entra ID for production workloads to enable conditional access, managed identities, and least privilege RBAC. API keys are convenient for quick evaluation and legacy tooling but lack user level traceability.
25+
26+
## Control plane vs. data plane
27+
28+
Azure services separate management (_control plane_) from runtime operations (_data plane_).
29+
30+
| Plane | Scope in Azure AI Foundry | Typical operations | Example tools | Authorization surface |
31+
|-------|---------------------------|--------------------|---------------|-----------------------|
32+
| Control plane | Setting up and configuring hubs, projects, networking, encryption, and connections | Create or delete resources, assign roles, rotate keys, set up Private Link | Azure portal, Azure CLI, ARM templates and Bicep, Terraform | Azure RBAC (management actions and dataActions) |
33+
| Data plane | Running and using model inference, agent interactions, evaluation jobs, and content safety calls | Chat completions, embedding generation, start fine-tune jobs, send agent messages, analyzer and classifier operations | SDKs, REST APIs, Azure AI Foundry portal playground | API key header or OAuth 2.0 (Microsoft Entra ID token) plus dataActions |
34+
35+
### Control and data plane diagram
36+
37+
![Diagram that shows the control plane (configuration, role assignments, networking, keys) influencing data plane operations (model inference, agent service, evaluations, content safety).](../media/authentication-options-ai-foundry/control-data-plane.png)
38+
39+
_Source file: control-data-plane.mmd (stored alongside the image for maintenance; not published)._
40+
41+
> [!NOTE]
42+
> This diagram is conceptual. Check current service documentation for the latest supported resources and operations.
43+
44+
## Authentication methods
45+
46+
### API keys
47+
48+
API keys are static secrets scoped to an Azure AI Foundry resource (formerly Azure AI Services).
49+
50+
**Recommended for:**
51+
- Rapid prototyping and isolated test environments
52+
- Systems where rotating a single secret across multiple callers is operationally acceptable
53+
54+
**Advantages:** Simple, language agnostic, and doesn't require a token acquisition flow.
55+
56+
**Limitations:** Can't express user identity, is difficult to scope granularly, and is harder to audit. Disable API keys after you complete Microsoft Entra ID adoption.
57+
58+
### Microsoft Entra ID (token-based and keyless)
59+
60+
Microsoft Entra ID uses OAuth 2.0 bearer tokens. Principals get tokens for the resource scope (`https://cognitiveservices.azure.com/.default`).
61+
62+
**Recommended for:**
63+
- Production workloads
64+
- Conditional Access, MFA, and just-in-time access
65+
- Least privilege RBAC and managed identity integration
66+
67+
**Advantages:** Fine-grained role assignments, per-principal auditing, controllable token lifetimes, automatic secret hygiene, and managed identities for services.
68+
69+
**Limitations:** Has slightly higher initial setup complexity and requires custom subdomain endpoints for some services. See [Configure keyless authentication with Microsoft Entra ID](../foundry-models/how-to/configure-entra-id.md).
70+
71+
## Feature support matrix: API key vs. Microsoft Entra ID
72+
73+
> [!IMPORTANT]
74+
> Validate features marked [**TO VERIFY**] against current release notes if you rely on them for compliance-critical scenarios.
75+
76+
| Capability or feature | API Key | Microsoft Entra ID | Notes |
77+
|---------------------|---------|--------------------|-------|
78+
| Basic model inference (chat, embeddings) | Yes | Yes | Fully supported. |
79+
| Fine-tuning operations | Yes | Yes | Entra ID provides per-principal audit. [**TO VERIFY**] |
80+
| Agents service interactions | Yes | Yes | Use Entra ID for managed identity tool access. |
81+
| Content safety analyze calls | Yes | Yes | Use RBAC to limit high-risk operations. |
82+
| Batch analysis jobs (Multimodal Intelligence) | Yes | Yes | Entra ID is recommended for large-scale labeling. [**TO VERIFY**] |
83+
| Portal playground usage | Yes | Yes | Playground uses project connection authentication mode. |
84+
| Network isolation with Private Link | Yes | Yes | Entra ID adds Conditional Access benefits. |
85+
| Conditional Access and MFA enforcement | No | Yes | Key-based auth bypasses user identity. |
86+
| Least privilege with built-in and custom roles | Limited | Yes | Keys provide all-or-nothing access per resource. |
87+
| Managed identity (system-assigned or user-assigned) | No | Yes | Enables secretless service-to-service auth. |
88+
| Per-request user attribution | No | Yes | Token includes tenant and object IDs. |
89+
| Revocation (immediate) | Rotate key | Remove the role or disable the principal | Short token lifetime still applies. |
90+
| Support in automation pipelines | Yes (secret) | Yes (service principal or managed identity) | Entra ID avoids secret rotation overhead. |
91+
92+
## Identity types
93+
94+
| Identity type | Description | Typical use in Foundry | Advantages | Considerations |
95+
|---------------|-------------|------------------------|------------|----------------|
96+
| User principal | Individual user in Entra ID | Portal, exploratory dev, model evaluation | Fine-grained auditing, Conditional Access policies | Not ideal for unattended jobs |
97+
| Service principal (app registration) | Application identity that uses a client secret or certificate | CI/CD pipelines, batch orchestration, external systems | Supports automation, supports certificate auth | Secrets and certificates must be rotated, avoid assigning overly broad roles |
98+
| Managed identity (system-assigned) | Azure resource-bound identity automatically managed by the platform | Deployed services calling Foundry (Functions, Web Apps, Container Apps) | No secret management, lifecycle tied to the resource | Works only in Azure, can't be used outside the cloud |
99+
| Managed identity (user-assigned) | Standalone identity that attaches to multiple resources | Share a workload identity across apps and define a rotation boundary | Reusable across hosts, enables granular role scoping | Lifecycle is decoupled—you must manage it separately |
100+
101+
## Built-in roles overview
102+
103+
See the authoritative list in [Azure built-in roles (AI + machine learning)](/azure/role-based-access-control/built-in-roles#ai-+-machine-learning). Common examples:
104+
105+
| Scenario | Typical built-in role(s) | Notes |
106+
|----------|--------------------------|-------|
107+
| Consume inference only | Cognitive Services User or Cognitive Services OpenAI User | Grants data plane usage. Doesn't allow management plane writes. |
108+
| Manage deployments or fine-tune models | Cognitive Services OpenAI Contributor | Includes permissions to create or update model deployments. |
109+
| Rotate keys or manage resource | Cognitive Services Contributor | Broad. Consider a custom role for least privilege. |
110+
| Observability and metric reads | (Varies) Cognitive Services User plus monitoring roles | Combine with Azure Monitor Reader if needed. |
111+
112+
> [!TIP]
113+
> Create a custom role when a built-in role grants more permissions than you need.
114+
115+
## Set up Microsoft Entra ID
116+
117+
High-level steps. See the detailed guide: [Configure key-less authentication](../foundry-models/how-to/configure-entra-id.md).
118+
119+
1. Ensure your Azure AI Foundry resource has a custom subdomain configured. See [Custom subdomains](/azure/ai-services/cognitive-services-custom-subdomains).
120+
1. Assign the needed built-in or custom role, such as Cognitive Services User, to each principal—user, service principal, or managed identity—at the resource or project scope.
121+
1. For a service principal, create an app registration, add a client secret or certificate, and note the tenant ID, client ID, and secret or certificate.
122+
1. For a managed identity, enable the system-assigned identity on the calling service or attach a user-assigned identity, then assign a role to it on the Azure AI Foundry resource.
123+
1. Update project connections in Azure AI Foundry to use Microsoft Entra ID: Management center > Connected resources > Access details > Authentication > Microsoft Entra ID.
124+
1. Remove key-based authentication after all callers use token authentication. Optionally disable local authentication in deployment templates.
125+
126+
### Example: Contoso mixed workload scenario
127+
128+
![Diagram that shows developers, a CI/CD service principal, and a managed identity enabled Azure Function interacting with an Azure AI Foundry resource while a security admin applies RBAC and Azure Monitor and tracing receive logs.](../media/authentication-options-ai-foundry/contoso-mixed-scenario.png)
129+
130+
_Diagram source file: contoso-mixed-scenario.mmd (stored with the image for maintenance; not published)._
131+
132+
- Give developers the `Cognitive Services User` role for inference.
133+
- Give the service principal a custom role that allows deployment and evaluation actions.
134+
- Give the managed identity for the Azure Function only the inference dataActions.
135+
- Security admin reviews role assignments regularly.
136+
137+
## Common setup scenarios
138+
139+
### Scenario: Restrict users to model inference but not agents
140+
1. Create a custom role that excludes agent dataActions.
141+
1. Assign users the custom role and the `Cognitive Services User` role if they need baseline inference.
142+
1. Attempt an agent action to confirm it's denied.
143+
144+
### Scenario: Separate admins (configuration) from developers (build)
145+
1. Assign a minimal management plane custom role to admins (resource write and delete plus networking; no dataActions).
146+
1. Assign developers data plane roles (for example, Cognitive Services OpenAI User or a custom role) without management plane delete rights.
147+
1. Review assignments periodically by using Azure Access Reviews.
148+
149+
### Scenario: Least-privileged project access
150+
1. Inventory required operations (inference, fine-tuning, evaluation, content safety).
151+
1. Start with the narrowest built-in role that covers most needs, and clone it into a custom role.
152+
1. Add only needed dataActions for additional features; avoid wildcards.
153+
1. Test with a nonprivileged principal. Expand incrementally.
154+
1. Automate assignment by using IaC (Bicep/ARM) for consistency.
155+
156+
## Service authentication patterns
157+
158+
| Pattern | Description | Example | Recommended identity |
159+
|---------|-------------|---------|----------------------|
160+
| Server-to-service (headless) | Backend runs inference for users. | API layer that enriches chat responses. | Managed identity (preferred) or service principal |
161+
| Client app direct call | Front end calls the inference service (don't expose secrets). | Native or mobile app | Use a secure backend token broker. Don't embed keys. |
162+
| Data pipeline batch | Nightly batch fine-tunes models or runs evaluations. | Scheduled job | Service principal with limited custom role |
163+
| Agent tool access to Azure resources | Agent calls other Azure services through tools. | Retrieval augmentation | Managed identity with least privilege |
164+
165+
## Auto role assignments
166+
167+
Some creation workflows can auto assign broad roles, such as granting the resource creator the Owner or Contributor role. Review roles and downgrade them to least privilege right after provisioning. Document any automation that depends on elevated roles.
168+
169+
## Auditing and monitoring
170+
171+
- Use Azure Monitor logs and activity logs to correlate RBAC changes with data plane usage.
172+
- Enable diagnostic settings to export to Log Analytics or a SIEM.
173+
- Scan regularly for principals that still use API keys and migrate them to Entra ID.
174+
175+
## Related content
176+
177+
- [Authenticate requests to Azure AI services](/azure/ai-services/authentication)
178+
- [Configure key-less authentication with Microsoft Entra ID](../foundry-models/how-to/configure-entra-id.md)
179+
- [Azure built-in roles (AI + machine learning)](/azure/role-based-access-control/built-in-roles#ai-+-machine-learning)
180+
- [Managed identities for Azure resources](/entra/identity/managed-identities-azure-resources/overview)
17.9 KB
Loading
25.5 KB
Loading

articles/ai-foundry/toc-files/security-governance/toc.yml

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,8 @@
11
items:
22
- name: Identity & access management
33
items:
4+
- name: Authentication options
5+
href: ../../concepts/authentication-options-ai-foundry.md
46
- name: Role-based access control
57
href: ../../concepts/rbac-azure-ai-foundry.md
68
- name: Rotate API access keys

0 commit comments

Comments
 (0)