Skip to content

Support Microsoft Foundry authentication with Entra ID - #84

Merged
wch merged 3 commits into
mainfrom
ms-foundry-entra
Aug 25, 2026
Merged

Support Microsoft Foundry authentication with Entra ID#84
wch merged 3 commits into
mainfrom
ms-foundry-entra

Conversation

@wch

@wch wch commented Aug 25, 2026

Copy link
Copy Markdown
Collaborator

Microsoft Foundry connections currently require an API key, so organizations that disable key-based authentication cannot use their deployments. This change lets the built-in Microsoft Foundry provider use Microsoft Entra ID instead, acquiring and refreshing tokens through Azure CLI credentials, managed identity, workload identity, or an environment service principal. API-key authentication remains the default for existing configurations. If Azure credentials are unavailable, users receive an actionable message that directs them to run az login; token providers remain separate for different tenants and scopes.

Changes

  • Microsoft Foundry connections can select API-key or Entra ID authentication. Previously, all connections required an API key.
  • Entra mode acquires tokens at request time and stores no secret material. Previously, the provider had no keyless authentication path.
  • Applications can identify which Foundry connection fields come from user, administrator, environment, or default configuration. This lets configuration screens keep administrator-managed fields read-only without disabling fields users still control.
  • Custom Microsoft Foundry providers continue to require API keys; Entra mode applies only to the built-in provider.

Breaking changes

The Azure SDK dependencies require Node.js 22.12 or later. Consumers using an older Node.js release must upgrade before adopting this version.

Related to posit-dev/positron#15663

wch added 3 commits August 25, 2026 14:53
ai-config gains an `azure` connection section (authMode apikey|entra,
scope, tenantId) carried by the built-in ms-foundry key only, with
MS_FOUNDRY_DEFAULTS resolving an absent authMode to apikey and an absent
scope to https://cognitiveservices.azure.com/.default, plus
MS_FOUNDRY_AUTH_MODE / MS_FOUNDRY_ENTRA_SCOPE / MS_FOUNDRY_TENANT_ID env
overlays.

ai-credentials gains AzureEntraCredentials (azure-entra): baseUrl +
required scope + optional tenantId/customHeaders, and no secret material.

The bridge adds @azure/identity and a process-level cached
getBearerTokenProvider(DefaultAzureCredential) keyed by scope+tenant, with
token-acquisition failures normalized into an actionable az-login error.
The Foundry provider accepts azure-entra credentials: static model
discovery keys off baseUrl, and the client factory injects the bearer
token per request around the shared OpenAI-compatible fetch so
customHeaders and request/stream normalization still apply.
Surface a ResolvedConnectionFieldSource (user / enforced / environment /
default) for each UI-managed ms-foundry field — azure.authMode, azure.scope,
azure.tenantId, baseUrl — so configure forms can disable individually pinned
controls without re-deriving source precedence from resolved values.
@wch
wch merged commit b57b1ee into main Aug 25, 2026
4 checks passed
@wch
wch deleted the ms-foundry-entra branch August 25, 2026 19:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant