hussein-awala opened a new pull request, #72010:
URL: https://github.com/apache/airflow/pull/72010
Support Azure national clouds in the FAB auth manager's Azure AD id_token
validation.
**Draft — stacked on #71920.** This branches off that PR's head
(`fde8068296`) because both
touch the same functions. I'll rebase onto `main` once #71920 merges; review
it after that one.
## Why
Before #71735, `_decode_and_validate_azure_jwt` verified the signature and
called
`claims.validate()` with no issuer check, so any Azure cloud worked. #71735
added issuer
pinning built around a hard-coded `login.microsoftonline.com`, which means
deployments on
Azure Government (`login.microsoftonline.us`) or Azure operated by 21Vianet
(`login.partner.microsoftonline.cn`) can no longer authenticate at all: the
tenant cannot be
derived from their endpoints, so validation raises before a token is ever
examined.
There is a second, older problem in the same path. `_get_microsoft_jwks`
fetches keys from
`MICROSOFT_KEY_SET_URL`, which is the commercial cloud's `common` key set.
National clouds
sign with their own keys, so even with the issuer fixed, signature
verification would fail.
## What this does
Rather than hard-coding each cloud's issuer and key set — values that are
easy to get subtly
wrong — the acceptable issuers and the `jwks_uri` are read from the tenant's
own OpenID
discovery metadata:
* an allowlist of Microsoft authority hosts (commercial, US Gov, 21Vianet)
replaces the single
hard-coded host when deriving the tenant from configured endpoints;
* for a national cloud, the v2.0 and v1.0 discovery documents supply the
accepted `iss` values
and the `jwks_uri`, cached per (authority host, tenant);
* the commercial path is unchanged, including the fast path where a GUID
tenant resolves with
no network call, so existing deployments see no new latency and no
behaviour change.
Both the issuer and the `jwks_uri` are required to live on the configured
authority host, so a
tampered discovery document cannot point verification at another host. Every
failure path
raises `AzureTenantResolutionError`; if the v1.0 document cannot be read,
the v1.0 issuer is
simply not accepted, which denies a login rather than widening what is
trusted. Failures are
not cached.
Azure AD B2C is deliberately out of scope: its authority is per-tenant
(`<tenant>.b2clogin.com`) and its metadata is addressed by policy, which
does not fit a
tenant-only lookup. That is now stated in the docs rather than left to be
discovered.
## Tests
Nine tests: end-to-end validation on both national clouds asserting the key
set comes from the
tenant's metadata; a negative test that a commercial-issued token is
rejected for a national
cloud tenant; fail-closed cases for an issuer or `jwks_uri` pointing off the
configured
authority and for missing fields; a v1.0-document-unavailable case; caching;
and authority
host derivation including the fallback to commercial.
related: #71920, #71735
---
##### Was generative AI tooling used to co-author this PR?
- [X] Yes — Claude Code (Opus 5)
Generated-by: Claude Code (Opus 5) following [the
guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
