Forum Discussion
What service principal is used to authenticate Logic Apps to Azure resources?
This question is a bit more academic than practical, but I'm just trying to enhance my knowledge of how Azure authentication works under the hood. The default way to authenticate managed Logic Apps ...
Hi jbfeldman,
Speaking to the question asked in your post's subject first, the best places to find the answer are either:
- Easiest approach: Under Logic apps blade in the Azure Portal;
- Moderate approach: Check the sign-in logs in the Azure Portal;
- Hardest approach: Under App registrations (not Enterprise applications) in the Entra ID blade in the Azure Portal..
Under logic apps
This is covered well-enough by the Microsoft documentation - which I'll link below, but one thing I wanted to point out is that you will have one identity per logic app. It's not a case of having a single servicePrincipal that automatically services all logic apps.
Technically, you can create a single user-managed servicePrincipal object and use it for all your Logic Apps, but this would be unusual and not wise to pursue as a default approach. User-managed identities are very useful in specific scenarios but they should be used only when needed, not by default.
Under sign-in logs
This is also adequately-covered by the Microsoft documentation, so I'll simply link it here:
Under app registrations
Within the Entra ID blade, choose App registrations and then All applications, as shown below.
Depending on how many registrations your organisation has and how good the naming convention is (or isn't), this approach can be like looking for a needle in a haystack.
Additional information
While every registered enterprise application will have an underlying servicePrincipal (which will surface in the App registrations section), the inverse is not true: servicePrincipals can be created as standalone (i.e. No matching enterprise app) to serve automation purposes.
Not seeing any Azure management API rights for the userPrincipal is not uncommon since the preferred approach is to use role-based access to define access rights. Role-based access can be inspected under the Roles and administrators menu item as shown below.
Cheers,
Lain
Hi Lain, this is not really correct. What you're describing is only true if you use managed identities to authenticate logic apps. While you can use managed identities in Logic apps (which as in the docs you linked, will create a Service Principal for each logic app) it is not required. My question is specifically about the scenarios where you do not use a managed identity for authentication, and instead use Oauth for authentication. Most Microsoft-built logic app connectors will let you choose between the two
For connectors using the Graph API, as I stated, I was able to find the Service Principal (which can be used by multiple logic apps) that was used to authenticate the connection. But I'm struggling to find a similar Service Principal for connectors that use the Azure Resource Management API
Hi jbfeldman,
I wouldn't mind knowing which part of what I outlined is incorrect.
I can't really add anything new for your first question around discovering which servicePrincipal is used for which app, while for you second, (covered under "additional information"), I can only reinforce that it's quite normal for permissions to not show on the screen you have in your original post since they're most commonly assigned via roles, not the individual API categories (Azure API rights are broken into many separate categories).
Expanding on Azure rights a little, if roles are what I see being used the most, then second on the list would be the direct assignment of rights to resources such as subscriptions and resource groups, which also doesn't surface on the API permissions screens.
Cheers,
Lain
