Security Principals, Service Principals, and Managed Identities

A security principal in Azure is an object that represents a user, group, service principal, or managed identity, and is used to request access to Azure resources."

User Principal: represents an individual user which are given access to particular resources through Microsoft Entra ID.

• Example: Giving Bob's user account access to a Azure Storage Container so that he can access files needed for his accounting job.

Group Principal: represents a group of users which are given access to particular resources through Microsoft Entra ID.

• Example: Giving the accounting group access to a azure storage container so that they can access files needed for their accounting job.

Service Principal: an object in Microsoft Entra ID that represents an identity for an instance of an application (usually created from an App Registration), which allows the application to authenticate and access specified Azure resources.

App Registration → creates Service Principal → Service Principal grants access to Azure resources

• Example: The software development team created an external application for the accounting team. The app is registered via App Registration, which creates a Service Principal used to authenticate the app and grant it read access to an Azure Storage container.

Managed Identity: a fully managed Microsoft Entra ID object that provides an identity to an Azure resource to allow it to utilize other azure resources.

• User-Assigned: independent identity that can be associated with multiple different azure resources.
  • Example: There are three webapps that required access to a Cosmos DB instance in order to store financial transactions. You can create a user-assigned managed identity to give contributor role access to all three of the webapps at once.
• System-Assigned: a fully managed Microsoft Entra ID object that provides a one-to-one identity allowing an Azure resource to utilize another Azure resource.
  • Example: Giving a singular webapp contributor role on a Cosmos DB instance in order to store only the financial transaction from the individual webapp.

When would I choose a system-assigned managed identity vs a user-assigned managed identity in a production Azure architecture?

You would choose a system-assigned managed identity when you want an identity that is tied to the lifecycle of a single Azure resource, it is automatically created and deleted with the resource and is used when only that resource needs access to another Azure service. You would choose a user-assigned managed identity when you want to share a single identity across multiple Azure resources, or when you want to manage the identity’s lifecycle and role assignments independently of any individual resource.