Pierre Villard created NIFI-16387:
-------------------------------------
Summary: Support Microsoft Entra access token authentication for
SQL Server in DBCP services
Key: NIFI-16387
URL: https://issues.apache.org/jira/browse/NIFI-16387
Project: Apache NiFi
Issue Type: Improvement
Components: Extensions
Reporter: Pierre Villard
Assignee: Pierre Villard
The Azure Entra Database Password Provider currently requests an Azure OSS
RDBMS token and supplies it through the JDBC password property. This works for
Azure Database for PostgreSQL and Azure Database for MySQL.
Microsoft SQL Server and Azure SQL instead require Microsoft Entra tokens
through the Microsoft JDBC Driver *accessToken* connection property. The
existing database password provider contract does not describe where a
generated credential should be placed, so the DBCP service cannot correctly use
the Azure provider for SQL Server.
The goal is to extend the database password provider API with a typed
credential-placement contract supporting:
- PASSWORD
- ACCESS_TOKEN
Existing providers default to PASSWORD, preserving compatibility.
We then update the provider-aware DBCP data source to create attempt-local JDBC
properties for every physical connection. For access-token placement, it:
- Removes existing user, userName, and password properties case-insensitively.
- Sets canonical blank user and password properties.
- Sets the generated credential as accessToken.
- Preserves other JDBC properties, including authentication and
integratedSecurity, so the JDBC driver remains responsible for validating
incompatible configurations.
- Clears the provider-returned credential array and removes the attempt-local
credential after the connection attempt.
Add a database target property to the Azure Entra Database Password Provider:
|Target|Token scope|JDBC placement|
|Azure OSS
Database|[https://ossrdbms-aad.database.windows.net/.default]|Password|
|Microsoft SQL Server|[https://database.windows.net/.default]|Access token|
The Azure OSS Database target remains the default, so existing configurations
require no migration.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
