Before I get into the technical details, let me first explain the context of this post.
Every application or website that you use today is a collection of many different components. Those components need to speak to each other to provide you with a certain functionality.
The most basic components would be a database, a storage account, and an application server.
So far with me?
Now, when these componets are all across multiple cloud providers, or even on-premises, they need a way to authenticate and authorize each other.
That's where Service Principals come in. Think of a Service Principal as a "user" that represents an application or service. It has its own credentials and can be granted permissions to access resources.
Now, what if all your components are in Azure? Do you still need to manage Service Principals and their credentials?
No, you don't.
Managed Identity is a feature of Azure Active Directory that provides Azure services with an automatically managed identity in Azure AD. You can use this identity to authenticate to any service that supports Azure AD authentication, without having to manage credentials.
Think of it like Azure giving your application a name tag that says "This is ServiceABC, and ServiceABC is allowed to do connect to DatabaseXYZ."
Here, ServiceABC and DatabaseXYZ are both Azure resources, and they can authenticate to each other using their Managed Identities.
So, if Managed Identity is so great, why do we have two types of Managed Identities: System-assigned and User-assigned?
It is like if you already had a name given by Azure, why would you need to create a new name for your application?
That's exactly we are going to explore in this post.
The difference between System-assigned and User-assigned Managed Identity becomes much easier to understand with a very non-technical example.
Enters the Saasu Maa (Mother-in-law)
Think of the typical Bollywood household.
There comes a point when, after you've somehow survived all the family drama and proved yourself worthy, Saasu Maa hands you the giant ring of keys, while some cringe worthy music plays in the background.
The keys to their so called "Safe / Tizori". The rooms. The storeroom. Everything.
Those keys aren't really about you.
They represent the responsibility you've been given.
Today you may be holding them.
Tomorrow, someone else might.
The keys still exist.
That is roughly how a User-assigned Managed Identity works.
But System-assigned is a little different.
Think of the key to your own room.
The key exists because the room exists.
If the room goes away, the key doesn't have much of a purpose anymore.
That's the basic difference.
Now, let's get back to Azure.
System-assigned: "I am this application or resource"
Suppose you have an Azure Function.
You enable Managed Identity on it, and Azure creates an identity specifically for that Function.
Azure Function
│
▼
Its identity
│
▼
Key Vault
You can then give that identity permission to access Key Vault.
The important part is the lifecycle.
The identity belongs to the Function.
Function exists -> identity exists.
Function is deleted -> identity is deleted.
It's like the key to your room.
Simple. Clean. And for many scenarios, exactly what you want.
User-assigned: "I represent this role"
Now imagine you don't want the identity to belong to one particular resource.
You want an identity representing something like:
Data Ingestion
That identity could then be assigned to multiple resources:
Data Ingestion Identity
│
┌────────┼────────┐
▼ ▼ ▼
ADF Function Logic App
The identity exists independently.
You can remove the Function tomorrow, create another one next month, and the identity can continue to exist.
That's the big advantage.
The identity represents a role or capability, rather than one specific Azure resource.
Much like that giant ring of keys.
So which one should I use?
This is where I think the distinction becomes useful.
Don't ask:
"Which Managed Identity is better?"
Ask:
"What should this identity represent?"
If the identity belongs to one specific application or resource, System-assigned is usually the simplest choice.
If the identity needs to exist independently, move between resources, or deliberately be shared by multiple resources, User-assigned starts making sense.
There is one important catch, though.
If three applications share the same identity, they effectively share the permissions given to that identity.
So this:
Shared Identity
/ | \
ADF Function App
means all three may have access to whatever that identity has been granted.
That's a good thing if that's what you want.
And, if done carelessly, it can be a security problem.
My rule of thumb
I generally think about it like this:
System-assigned
This identity belongs to this application.
User-assigned
This identity belongs to a role, and applications can use that role.
So unless I have a reason to make the identity independent of the resource, I'd start with System-assigned Managed Identity.
No extra identity resource to manage. No unnecessary sharing. Nice and simple.
Use User-assigned when the architecture actually calls for that separation.
And that's really all there is to it.
You don't need to remember a dozen Azure definitions.
Just remember the Bollywood household:
System-assigned: the key belongs to the room.
User-assigned: saasu maa hands you the giant ring of keys because you're now responsible for the house.
Thank you for reading! I hope this analogy helps you understand the difference between System-assigned and User-assigned Managed Identity in Azure.
For any questions, suggestions or feedback, please feel free to reach out to me on LinkedIn Manish K. Narang or post your comments below. I would love to hear your thoughts and experiences on this topic!