Difference between Service Principal and Managed Identities in Azure

Question

I would like to know if it is always recommended to use Managed Identities in Azure , mostly system assigned or a Service Principal? When should Service Principals be used in Azure compared to a managed identity, what is the advantage of one over the other? Any help would be appreciated.

Xantho

Have you tried searching for it yet? There's quite some information available... – Quinonez

Answer 1

Internally, managed identities are service principals of a special type, which are locked to only be used with Azure resources. When the managed identity is deleted, the corresponding service principal is automatically removed. Also, when a User-Assigned or System-Assigned Identity is created, the Managed Identity Resource Provider (MSRP) issues a certificate internally to that identity.

Source: What are managed identities for Azure resources?

and

So what’s the difference?
Put simply, the difference between a managed identity and a service principal is that a managed identity manages the creation and automatic renewal of a service principal on your behalf.

Source: What’s an Azure Service Principal and Managed Identity?

Quinonez

This answer does not make sense, because user-assigned managed identities also exist. learn.microsoft.com/en-us/azure/active-directory/… – Engineman

Hi @AtteJuvonen, the answer actually does make sense, since the basic information is correct: "managed identities are service principals of a special type, which are locked to only be used with Azure resources" and "a managed identity manages the creation and automatic renewal of a service principal on your behalf". Even if the Managed Identity you're creating is a User Managed one, the platform manages the Service Principal. – Quinonez

Thanks for the answer @rickvdbosch. Azure docs give the impression that "user-assigned" managed identities are not automatically created, but instead are created by the user. Here's a direct quote: "You can create a user-assigned managed identity and assign it to one or more instances of an Azure service". This sounds to me that the user is responsible for creating the service principal; it is not created "on behalf of the user". Or maybe there is some distinction between service principal and managed identity that I do not understand. – Engineman

That's partially correct: a user assigned managed identity is created by the user. The underlying service principal that's used for accessing resources, however, is being created and automatically renewed for the user. So every type of managed identity (both system and user assigned) is an abstraction of an underlying Service Principal. – Quinonez

@AtteJuvonen - The only difference is, that a managed identity is always linked to an Azure Resource, unlike an application or 3rd party connector mentioned above. They are automatically created for you, including the credentials; big benefit here is that no one knows the credentials – Kleeman

Answer 2

Service Principal

We can say the most relevant part of the Service principal is the Enterprise Apps section under Azure Active Directory. This is basically an application that will allow your user apps to authenticate and access Azure resources, based on the RBAC.

It essentially is an ID of an application that needs to access Azure resources. In layman’s terms, imagine if you have to assign certain access to your colleague so that he\she can access Azure resources and perform required tasks, you can use their email id as a way to authenticate the user.

Managed Identity

We can say that the Managed Identities are actually Service Principals and they are identical in the functionality and purpose they serve.

The only difference is, that a managed identity is always linked to an Azure Resource, unlike an application or 3rd party connector mentioned above. They are automatically created for you, including the credentials; big benefit here is that no one knows the credentials

There are two types of managed identities:

1.) System assigned; in this scenario, the identity is linked to a single Azure Resource, eg a Virtual Machine, a Web App, Function,… so almost anything. Next, they also “live” with the Azure Resource, which means they get deleted when the Azure Resource gets deleted.

2.) User Assigned Managed Identity, which means that you first have to create it as a stand-alone Azure resource by itself, after which it can be linked to multiple Azure Resources. An example here could be out of integration with the Key Vault, where different Workload services belonging to the same application stack, need to read out information from Key Vault. In this case, one could create a “read KV” Managed Identity, and link it to the web app, storage account, function, logic app,… all belonging to the same application architecture.

Kleeman

I like your answer as it puts both System MSI and User MSI along with SP. Could you please improve your answer with highlights why there is a need for User MSI when there is already SP? – Chin

@RajeshSwarnkar - There is no need to have seperate user MSI, if there is SP exist. you can authenticate the azure resource through SP. but there is extra burden to maintain it. so in azure each resource designed for specific need. user MSI has it own advantages over SP. – Kleeman

Answer 3

A managed identity is a type of the service principal.

A service principal can be one of three types: application, managed identity, and legacy. The division into types is based on circumstances of their usage. Thus their specific handling also differs based on their type.

rickvdbosch provided link to an article that talks about specifics of the managed identity type of the service principal. For those who would like to learn about the concept of the service principal object and its types, here is a link to a different article: Application and service principal objects in Azure Active Directory.

Piss

Answer 4

An Azure service principle is like an application, whose tokens can be used by other azure resources to authenticate and grant access to azure resources.

Managed identities are service principals of a special type, which are locked to only be used with Azure resources.

The main difference between both is that in managed identity you don’t need to specify any credentials in your code compared to service principles where you need to specify application id, client id, etc to generate a token to access any Azure resource. Ideally, you should opt for service principal only if the service you use doesn’t support managed identity.

Moynihan

If they don't have credentials, then how do you log in? – Peculiar

You log in from your local env using your already logged in azure account (to develop locally), and when the app is in azure it uses that managed identity to auth against the azure resources. In both cases, the code doesn't change and no credentials, tokens, secrets etc are specified in the code. That's the difference. – Roble

Answer 5

(Pros) How are managed identities different from service principals?

1. They are always linked to an Azure Resource, not to an application or 3rd party connector.

2. They can be automatically created for you on resource creation (for resources that support wielding managed identities.

   There are 2 "flavors": user-assigned and system-assigned. The above sentence refers to the latter; even if not set up on resource creation, it can be enabled with one click.

3. No credentials are needed as managed identities use access tokens.

   To set up service principals, one needs to provide the client ID, tenant ID, and password / secret for a service (e.g., as environment variables).

   In contrast, accessing target resources from / through MSI resources is done through access tokens.

(The items were originally taken from the Demystifying Service Principals – Managed Identities article, but re-phrased them enough that directly quoting them wasn't applicable.)

Cons

In my opinion, it's the complexity:

• One has to have a thorough understanding of the terms "identity", "security principal", "service principal", "role" etc. and how they relate to each other.

• Tokens are not straightforward to use.

  The docs are all over the place, and most of the stuff I did was through trial and error (... and looking up lots and lots of error messages online).

  For example, requesting a token requires using the root resource URI (in the case of key vaults, it is https://vault.azure.net), and it needs to be used on the specific target resource. The latter is straightforward, but not the former. Not sure where this is spelled out in the docs, but it sent me down the rabbit hole for a while (see e.g., this thread).

• Some other quirks

  CAVEAT
  These may not be an issue in other tools such as Azure CLI - or I may have overlooked stuff...

  • Finding managed identities (MSIs) on the Portal

    User-assigned MSIs have a their own sub-category "Managed Identities", but this won't show system-assigned ones. The latter need to be searched individually.

  • Resource groups and MSIs

    This is only based on my experiences on the Portal, but it seems that system-assigned MSIs don't belong to a resource group (or they are hidden). That is, user-assigned ones show it clearly when called up, but couldn't find this info for system-assigned MSIs, and it doesn't make sense. The latter are tied tightly to the MSI resource so I went to the particular resource's resource group, listed all members, but they also don't show up there. Weird.

Terms

A quick overview of Azure identities (where "identity" refers to Azure Active Directory identities):

    │
    ├─► user
    │
    ├─► group
    │                  managed
    └─► service  ────► identity
       principal      (MSI)

• service principal

  A security identity used by applications or services to access specific Azure resources. You can think of it as a user identity (username and password or certificate) for an application.
  ^{(from Steps to assign an Azure role})

  or

  "An application whose tokens can be used to authenticate and grant access to specific Azure resources from a user-app, service or automation tool, when an organization is using Azure Active Directory"

  In essence, by using a Service Principal, you avoid creating “fake users” (we would call them service account in on-premises Active Directory…) in Azure AD to manage authentication when you need to access Azure Resources.
  ^{(from Demystifying Service Principals – Managed Identities)}

• managed identity (MSI)

  A managed identity (MSI) is a special kind of service principal that is assigned to an Azure resource that supports wielding managed identities to access other Azure services / resources without credentials.
  ^{(from this answer)}

  Managed Identities are in essence 100% identical in functionality and use case than Service Principals. In fact, they are actually Service Principals.
  ^{(from Demystifying Service Principals – Managed Identities)}

• MSI resource: an Azure resource that support having (or endowed with) managed identities

• target resource: an Azure resource that the MSI resource is trying to access

Interweave

Answer 6

Managed Identities are tied to a resource (VM, Logib App, etc). To give the resource grants and permissions for accessing(CRUD) other resources you use Managed Identities.

Service Principial do not have to be tied to a resource, they leave under tenant and above subscription, and what is more is more important - have some auth tokens that could be stored somewhere (Key Vault). It is like a fake user with some credentials and tokens.

Denature

Answer 7

A Service Principal could be looked at as similar to a service account-alike in a more traditional on-premises application or service scenario. Managed Identities are used for “linking” a Service Principal security object to an Azure Resource like a Virtual Machine, Web App, Logic App or similar

Incogitable