A security principal is the “who” in Azure access control: an identity-bearing object that can request access to a resource. It must exist in Microsoft Entra ID and may represent a user, group, application, or another identity. section 6.7.1
Common security principals include:
- A user, such as Joe from accounting. section 6.7.1
- A group, such as sysadmin, allowing access to be managed for multiple people. section 6.7.1 section 6.9
- An application, such as the Alpaca-Ma-Bags order system. section 6.7.1
- A service principal or managed identity, used by applications and Azure services to access resources without relying on a human account. section 6.9
A principal does not receive useful permissions by itself. Azure RBAC combines the principal with a role definition describing what it can do and a scope describing where those permissions apply. Together, these form a role assignment. section 6.7 section 6.7.3
An application limited to one resource group
Give the Alpaca-Ma-Bags application the built-in Contributor role at the AlpacaRG resource-group scope. The application becomes the principal, Contributor supplies the permissions, and the resource group limits where those permissions apply. Built-in roles are preferred when possible because custom roles require ongoing permission and naming maintenance. section 6.7.3
Figure 6.33 RBAC components
Use the RBAC components diagram to see how the principal, role definition, and scope combine into authorization. section 6.7
