Difference between "System Assigned" Identity and App Registration "Service Principal"

Question

Can someone help me understand the difference between the Service Principal created when I create an App Registration in AAD and the Managed Identity that gets created when I enable "System Assigned" on the Identity blade of an App Service?

We have an App Service that we are developing that we have created an App Registration for and we have also enabled the System Assigned identity. When we go into Enterprise Applications under AAD and search for our app, it comes up with 2 entries. One for the Managed Identity and one for the Service Principal created as part of the App Registration. We are trying to understand which one we would use to give the app permissions to write to an Azure SQL DB.

Answer 1

Managed Identities are essentially service principals wrapped with Microsoft logic to make accessing resources simpler. Although, sometimes adding more layers may complicate things, the idea is to make it easier, simpler, and less consumer interactive.

For your scenario, you'll want to think about what you would like to do. Would you like to have more control and implement your own logic with an Azure SQL DB protected by AAD, or try utilizing Microsoft's Managed Identity to protect/access the Azure SQL DB resource. (Ideally the Managed Identity path should be less work)

The tutorial for using Managed Identities to access an azure SQL db from an app service can be found here : https://learn.microsoft.com/en-us/azure/app-service/app-service-web-tutorial-connect-msi

The docs for protecting an Azure SQL DB using Azure AD can be found here : https://learn.microsoft.com/en-us/azure/sql-database/sql-database-aad-authentication

Furthermore Managed Identities are explained in the official Microsoft documentation here : https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview

It's important to note that there are two kinds of Managed Identities.

From the documentation:

A system-assigned managed identity is enabled directly on an Azure service instance. When the identity is enabled, Azure creates an identity for the instance in the Azure AD tenant that's trusted by the subscription of the instance. After the identity is created, the credentials are provisioned onto the instance. The lifecycle of a system-assigned identity is directly tied to the Azure service instance that it's enabled on. If the instance is deleted, Azure automatically cleans up the credentials and the identity in Azure AD.

A user-assigned managed identity is created as a standalone Azure resource. Through a create process, Azure creates an identity in the Azure AD tenant that's trusted by the subscription in use. After the identity is created, the identity can be assigned to one or more Azure service instances. The lifecycle of a user-assigned identity is managed separately from the lifecycle of the Azure service instances to which it's assigned.

The picture from the official docs also gives a good example of a VM using MSI(Managed Service Identity).

This is Provided below:

In addition to that, the App Service Managed Identity documentation can be found here : https://learn.microsoft.com/en-us/azure/app-service/overview-managed-identity

Answer 2

I would like to elaborate a little further as the topic around service principals and app registrations in Azure can be confusing.

As you noticed, a service principal will get created in your AAD tenant when you turn on system-assigned managed identity for a resource in Azure. This service principal is tied to the lifecycle of your resource or in other words: If you delete your App Service, Azure will delete the service principal for you [2].

Beside service principals, there are other object types that live inside a tenant: User principals and application objects. As the name suggests, user principals identify a user while a service principal can be used to either identify a resource in Azure or an application object. To both types of principals you can assign roles, as you mentioned you can create a new user in your database and use the system-assigned identity (Service Principal 1 in the image below) to let Azure SQL know that your App Service has permissions to access the database [3]. This is marked in red in the image.

When you create an app registration, two objects are created: An application object and a service principal in your tenant (this is "Service Principal 2") [4]. You could now use this service principal as well to give it permissions to access the database (marked in orange in the image) but this service principal is not tied to your Azure App Service and doesn't represent it. In other words, if you want to use Service Principal 2 in your App Service, beside creating a user for this service principal in your database you'd additionally also need to get an access token for this service principal whenever you create a new SQL connection to the database in your application. It's possible but a bit more inconvenient and the beauty of using system-assigned identities is that your App Service knows about its service principal already and you don't have to manage it on your own (e.g., delete it when your App Service gets deleted).

Long story short: Use the system-assigned managed identity in your use case.

[2] https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview#managed-identity-types

[3] https://learn.microsoft.com/en-us/azure/app-service/app-service-web-tutorial-connect-msi#grant-permissions-to-managed-identity

[4] https://learn.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals

Answer 3

You can only use the managed identity that you have enabled in your App Service for authentication to AAD which eventually allows you to access your Azure SQL instance based on roles/permissions. I'd tried using the service principal/Enterprise Application created as part of App Registration process for authentication and it didn't work. The way I see it is that the App Service is what runs/hosts your application and only this managed identity/SP is available to your running application for authentication to AAD. The Service principal/Enterprise Application is being used internally for some other purpose and, it is not available to our application for authentication to AAD.

Answer 4

Just a wee note. App Registration may live without Service Principal. App Registration may represent an application that is consumed, not necessarily the consumer.

Answer 5

Managed Identity is solely a client-based identity.

E.g. Your App Service is acting as a client, when accessing Azure SQL. In this case you don't need an app registration and its service principal at all. You will only need a Managed Identity (which is a Service Principal).

When your App Service (A) is opposed to access another App Service (B) then again your App Service (A) does not need an app registration. But App Service B needs to have an app registration.

Imo when you want to use the credential-less approach in Azure, an app registration is acting as the server part and a Managed Identity (system - or user-assigned) is considered to be the client part.