Forum Discussion
MicrosoftADF - Support for Federated Identity Credentials
Our team is working on migrating existing pipelines to Azure Data Factory (ADF). As part of this effort, we are evaluating ADF for executing Kusto commands and would like to use an existing Microsoft Entra application registration authenticated through Federated Identity Credentials (OIDC workload identity federation).
Today, ADF appears to primarily support Managed Identity-based authentication patterns. Is there any planned support for using a customer-owned App Registration with Federated Identity Credentials (FIC)? If so, is there any public roadmap or timeline that can be shared?
We are actively moving away from secret- and certificate-based authentication. Supporting FIC would allow us to continue using our existing application identities, which already have the required permissions on source and destination datasets, and would avoid the need to introduce additional User Assigned Managed Identities and request new permission grants from dataset owners as part of the migration.
2 Replies
Based on the current published connector schema, ADF’s Azure Data Explorer linked service does not expose a federated-token or client-assertion field. It supports system-assigned managed identity, user-assigned managed identity, or a service principal with a key. So an app registration that only has an FIC cannot be used directly by the Kusto Command activity today. I also could not find a public commitment or date for native FIC support.
For a fully secretless ADF design, the simplest supported option is the factory’s system-assigned managed identity. This avoids creating another UAMI, although the existing Kusto/database permissions must be granted to that identity. If preserving the current application identity is mandatory, move the token exchange and Kusto call into compute that supports workload identity federation and a Kusto SDK custom token provider, then invoke it from ADF. That adds a component, but keeps secrets and certificates out of the pipeline.
For roadmap confirmation, I would raise a support case or track an Azure Feedback request.
Short answer: ADF does not currently expose native workload identity federation for an App Registration in an Azure Data Explorer linked service. The current connector schema supports service principal authentication with a key, or system-/user-assigned managed identity; it has no issuer, subject, audience, or client-assertion fields needed for FIC.
I also cannot find a published Microsoft roadmap or timeline for this. The cleanest passwordless option today is to attach a user-assigned managed identity to the factory, create an ADF credential for it, and grant that identity the existing Kusto/database permissions. If retaining the current app registration is mandatory, the workaround is to place an Azure Function or Container Apps endpoint in front of the Kusto call and let that workload obtain the federated token, then invoke it from ADF—but that adds another component. I would open a support request or feature request for roadmap confirmation rather than design around an unpublished date.
