Forum Discussion
Can a service principal with federated credentials be used for SQL cloud connection auth?
Replacing OAuth 2.0 personal-account auth on our Fabric SQL cloud connections. Workspace identity doesn't fit, because semantic models in other workspaces share the same connection and each workspace has its own identity — those refreshes fail with invalid credentials unless every workspace identity is granted on the database.
A service principal solves that, but I'd like to avoid storing a secret. I added a federated identity credential to the app registration. In the connection settings, Service Principal auth only offers a key or a certificate, with nowhere to reference the federated credential.
Is that expected? I assume federation needs the caller to present a token it already holds, and the Fabric refresh engine has none — so it simply can't apply. Confirmation would be useful, as would any roadmap or Ideas link for secret less cloud connection auth.
If certificate is the answer, I'd also welcome hearing how others handle cert rotation across many connections given the encrypted payload on the update credentials API.\
Fabric SQL cloud connections only list service‑principal sign‑in by secret and by certificate. The refresh engine has no flow for getting a token through OIDC federation, so adding a federated credential to the app does not give Fabric a way to use it.
A small cert added and re‑saved in the connection settings is the simple and safe workaround beginners can use, and cert rotation just means re‑saving the updated cert in the same place.
5 Replies
- Kagiyama_yutaka
Continued Contributor
Fabric SQL cloud connections only list service‑principal sign‑in by secret and by certificate. The refresh engine has no flow for getting a token through OIDC federation, so adding a federated credential to the app does not give Fabric a way to use it.
A small cert added and re‑saved in the connection settings is the simple and safe workaround beginners can use, and cert rotation just means re‑saving the updated cert in the same place.
Kagiyama_yutaka Thanks for the clarification, the backup option I had was the workspace identities with no key rotation at all
v-kathullacCommunity Support
Hi CharlieFab ,
Sorry for the above reply that was my mistake. I was about to share the correct debugging steps to help resolve your issue, but I was in a hurry and accidentally posted the wrong steps.
Please find the correct debugging steps below to resolve the issue.
In the current Fabric connection experience, Service Principal authentication supports a service principal key or certificate, as shown in your screenshot, but there is no option to reference an Entra Federated Identity Credential (FIC).
FIC requires the calling service to obtain and present a federated token, and the Fabric-managed refresh process currently doesn't expose a way to configure that federated identity for the connection. So, FIC cannot currently be selected as the credential for this connection.
Since your requirement is to avoid storing a client secret, Service Principal certificate authentication is the available option shown in the connection UI. You would need to manage the certificate lifecycle/rotation and update the connection when the certificate changes.
For your scenario, where the same connection is shared by semantic models across multiple workspaces, using a dedicated Service Principal with certificate authentication can avoid granting every workspace identity access to the SQL database.
Thanks,
Chaithanya.- v-kathullac
Hi CharlieFab ,
Thank you for reaching out to Microsoft Fabric Community Forum, Below are the few points which can resolve your issue. Let us know if you need any further assistance.
Yes, this layout can be achieved in Power BI. The exact configuration depends on whether the fields are actual hierarchy levels or cost categories. If they are hierarchy levels, configure the Matrix as:
Rows: Customer → Job ID → Production → Department → Work Center
Values: Estimated Cost, Actual Cost, VarianceThen enable the +/- icons and stepped layout/drill-down so users can expand from Customer → Job ID → Production → Department → Work Center.
If Sales Price, Material, Outside Services, and Production are cost categories that should appear as separate rows with their corresponding Estimated Cost, Actual Cost, and Variance, I recommend using a disconnected Category table with SWITCH() measures instead of adding all of them as hierarchy levels.
This approach provides more control over the display and can more closely match the required layout. If you share the underlying fields/columns and the expected final Matrix layout, we can determine the appropriate approach and provide the exact DAX measures.
Thanks,
Chaithanyav-kathullac
Seems the incorrect thread
