[Mohit G (gmohit21)]

Why make this change?

Related to #3641.

Existing Azure SQL On-Behalf-Of (OBO) authentication requires an application client secret. This change adds a secretless alternative using managed identity federation, reducing secret-management overhead while preserving the caller's delegated SQL identity and existing client-secret configurations.

What is this change?

• Add DAB_OBO_MANAGED_IDENTITY_CLIENT_ID to select a user-assigned managed identity as the OBO application credential.
• Introduce OboCredentialFactory, which acquires a managed-identity token for api://AzureADTokenExchange/.default and supplies it through MSAL's asynchronous client-assertion callback. The caller's access token remains the separate OBO user assertion.
• Share credential validation between startup and runtime configuration validation. When OBO is enabled, require the API application/tenant IDs and exactly one credential method: client secret or managed identity federation.
• Reuse the credential and confidential client, support fresh assertion acquisition, preserve cancellation, and sanitize managed-identity acquisition errors without credential fallback.
• Add credential-factory, configuration and startup tests, together with federation configuration and troubleshooting documentation.

The federation option uses a same-tenant user-assigned managed identity on Azure public cloud, with a federated identity credential configured on the API app registration. Existing client-secret deployments remain supported. No new JSON configuration properties or CLI flags are introduced, and the existing SQL permissions/RLS model is unchanged.

How was this tested?

• Integration Tests
• Unit Tests

Manual Azure integration validation

• Deployed the feature build to Azure App Service backed by Azure SQL using a Visual Studio subscription, and verified the deployed binaries against the feature build.
• Configured and exercised managed-identity federation without an application client secret.
• Completed real browser testing with two separate users. Each user could retrieve their own salary data, while SQL RLS prevented access to the other user's data.

Local automated validation

The focused unit/regression suite passed 142 tests, with 0 failures and 0 skipped tests. Coverage includes credential selection, missing/conflicting configuration, separate application and user assertions, assertion reacquisition, cancellation, sanitized failures, startup registration and existing OBO regressions.

The full solution build passed with 0 warnings and 0 errors.

Commands executed from the repository root:

# PASSED: 0 warnings, 0 errors.
dotnet build .\src\Azure.DataApiBuilder.sln --no-restore --verbosity minimal

# PASSED: 142 tests; 0 failed; 0 skipped.
dotnet test .\src\Service.Tests\Azure.DataApiBuilder.Service.Tests.csproj --no-restore --filter "FullyQualifiedName~OboCredentialFactoryTests|FullyQualifiedName~OboSqlTokenProviderUnitTests|(FullyQualifiedName~ConfigValidationUnitTests&FullyQualifiedName~UserDelegatedAuth)|FullyQualifiedName~StartupTests.RegisterOboServices|FullyQualifiedName~SqlQueryExecutorUnitTests.SetManagedIdentityAccessToken_Obo" --logger "console;verbosity=minimal"

Sample Request(s)

On an Azure host with the user-assigned managed identity attached, federated trust configured, and the existing OBO configuration and SQL permissions in place:

$env:DAB_OBO_CLIENT_ID = "<api-app-client-id>"
$env:DAB_OBO_TENANT_ID = "<tenant-id>"
$env:DAB_OBO_MANAGED_IDENTITY_CLIENT_ID = "<user-assigned-managed-identity-client-id>"
Remove-Item Env:\DAB_OBO_CLIENT_SECRET -ErrorAction SilentlyContinue

dab start

The API request contract is unchanged. For an existing configured Salary entity:

GET /api/Salary

Authenticate the request using the caller's DAB-audience access token with bearer authentication. Federation changes how DAB authenticates its application identity during the OBO exchange; SQL access continues to use the delegated user's identity and permissions.

[Copilot]

🔵 Needs a closer look

The security-sensitive federation flow warrants final human review of Azure trust configuration and token lifecycle behavior.

No open issues 🎉

What changed in this PR

Adds secretless Azure SQL On-Behalf-Of authentication through managed identity federation, addressing the federation option requested in #3641 while preserving client-secret support and delegated user identity.

Changes:

• Adds a reusable credential factory that supplies managed-identity assertions to MSAL, with cancellation and sanitized failure handling.
• Shares credential validation between startup and runtime configuration, requiring exactly one credential method.
• Adds tests for credential selection, token requests, failure handling, and startup registration, plus environment-variable documentation.

File	Description
src/​Service/​Startup.cs	Registers OBO services through the shared credential factory.
src/​Service.Tests/​UnitTests/​StartupTests.cs	Tests registration and startup credential validation.
src/​Service.Tests/​UnitTests/​ConfigValidationUnitTests.cs	Expands validation coverage for both credential methods.
src/​Service.Tests/​Authentication/​OboCredentialFactoryTests.cs	Tests assertions, credential reuse, cancellation, and sanitized failures.
src/​Core/​Configurations/​RuntimeConfigValidator.cs	Shares credential validation and deduplicates process-wide errors.
src/​Core/​AuthenticationHelpers/​OboCredentialFactory.cs	Implements client-secret and managed-identity federation credentials.
src/​Config/​ObjectModel/​DataSource.cs	Defines and documents the managed-identity environment variable.

_{Review effort: Balanced}