We know that Azure Active Directory is Azure’s identity and access management service. In past few articles, we have seen how to register the applications in Azure Active Directory and then setup authentication.

For every application which is registered in Azure AD, two objects are created:

• Application Object, the Microsoft Graph Application entity defines the schema for an application object’s properties.
• Service Principal Object

What is service principal ?

From the documentation:

An Azure service principal is an identity created for use with applications, hosted services, and automated tools to access Azure resources. This access is restricted by the roles assigned to the service principal, giving you control over which resources can be accessed and at which level. For security reasons, it’s always recommended to use service principals with automated tools rather than allowing them to log in with a user identity.

So, in essence, the Azure service principle is like an identity, which is automatically created by Azure when an application is registered in the AAD. Azure AD creates them so that you do not have to create fake users in the AAD.

The security principal defines the access policy and permissions for the user/application in the Azure AD tenant. This enables core features such as authentication of the user/application during sign-in, and authorization during resource access.

For automated tools, they always need to gain restricted access and instead of asking them to sign in as fully privileged user, these tools can use service principals.

There are two types of authentication methods available for service principles, password and certificate.

What is Managed Identity ?

Let’s say, you have an application, running on Azure VM. And that application needs to upload some documents in Azure Blob storage.

Then you may take one of the two keys from Azure Storage to get your application authorized to upload the blob.

But this poses a problem. Now, this key needs to be kept with application, meaning developers, IT team are aware of it. Also, this key would be checked-in in the source control. Ideally, these keys should not be checked-in there.

Also, when administrators decide to rotate the Azure storage keys, the application will also need to be updated and new key needs to be checked-in again in source control.

So, how can this problem be solved ?

We can keep the Azure storage keys in Azure key vault thus decoupling application. So application does not need any update if the key rotation happens in Azure storage.

But there is new problem now. How will Azure key vault instance will know which applications should be authorized to read the keys ? So our application needs to know something so that it can get authorized.

Managed identities resolve this issue.

You can use the identity to authenticate to any service that supports Azure AD authentication, including Key Vault, without any credentials in your code. Every managed identity has an underlying service principal. When managed identity is deleted, the associated service principal is also deleted.

Managed identities manage the creation / renewal of service principals on your behalf.

There are two types of managed identities, user assigned managed identities and system assigned managed identities.

As you can guess, system assigned managed identities are generated by system, and they are tied to the instances of services for which they were created. As soon as the associated service instance is deleted, the system defined identity associated with it, would also be deleted.

User assigned managed identities are created by administrators. After creation, these identities are associated with one or more instances of services which support managed identities. Because this identity was not created for any specific resource, it’s lifecycle is not tied to any of the associated service instances. These type of identities needs to be explicitly deleted.

Managed service identities are convenient but as of today, not all Azure services support it. I hope this article provided basic information on the managed identities