What is the difference between roles and scopes in Azure's role-based access control (RBAC)?

Question

I'm reading the What is Azure role-based access control (Azure RBAC)? article in the official docs, but it is hard to discern how scopes and roles are different.

Read the following threads, but didn't find them helpful, because:

• stackoverflow: Scope/Role/Group Based Access Control

  It seems that the question isn't really what I'm asking, and the answers don't seem to agree with what I read. (Then again, this may be just poor reading comprehension on my part.) Anyway, the thread is from 2015, and the last update was in January 2016.

• stackoverflow: Is Microsoft Azure's Access Control service authentication model the same as role based access control?

  Doesn't expand on RBAC, only on AAC.

• stackoverflow: Role-Base Access Control in Azure web and database

  Only links to official docs or not related to this question.

• stackoverflow: What is the correct use of scopes and app roles in an Azure AD web api with user and daemon clients?

  Doesn't even try to explain roles vs. scopes.

Harter

Answer 1

Azure's RBAC is an authorization scheme

• (WHO)    to allow "an entity" (or "identity")  (in official terms, security principal)

• (HOW)    to access     (i.e., perform actions) (in official terms, role)

• (WHAT)  on a "set of resources"                    (in official terms, scope).

---

1. Building blocks of RBAC

1.1 Security principal¹ (the WHO)

The "entity requesting access to Azure resources" is formally called a security principal, and it can be one of the following: user, group, service principal, managed identity (MSI). (All these are commonly referred to as identities throughout the docs.)

This image from the docs

but a more accurate depiction would be:

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

The definitions (taken from Steps to assign an Azure role article in the official docs):

• user

  An individual who has a profile in Azure Active Directory. You can also assign roles to users in other tenants. For information about users in other organizations, see Azure Active Directory B2B.

• group

  A set of users created in Azure Active Directory. When you assign a role to a group, all users within that group have that role.

• 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.

  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)}

  See also: Create an Azure service principal with the Azure CLI

• managed identity

  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. (See this Stackoverflow thread for more.)

Additional reading:

• !devblogs.microsoft.com Demystifying Service Principals – Managed Identities
• endjin.com: Managing applications using Azure AD, service principals and managed identities: A permissions story
• stackoverflow: Difference between Service Principal and Managed Identities in Azure

1.2 Scope (the WHAT)

The official definition is that "a scope is the set of resources that the access applies to".

I like this simplified view, because, in the end, a scope does resolve to a set of resource, but more precisely it refers to an entity in a hierarchical tree structure, each of which has authority over an Azure resource:

• scope =/= Azure entity
• scope === resources assigned to Azure entity

The Understand scope for Azure RBAC is one of the most straightforward article in the Azure docs with great examples.

1.3 Role (the HOW)¹

As in, how is the security principal allowed to access the resource (i.e., scope).²

The docs are pretty straightforward about this one:

A role definition is a collection of permissions. It's typically just called a role. A role definition lists the actions that can be performed, such as read, write, and delete.

2. Role assignments - putting it all together¹

A role assignment "is the process of attaching a role definition to a user, group, service principal, or managed identity at a particular scope for the purpose of granting access."

That is, it is the application of a role definition to a security principal with a given scope. (I call role assignments "RBAC access rules" because it makes all this easier to remember and relate to.)

---

Footnotes

[1]: The distinction between role definitions (a.k.a., roles) and role assignments wasn't clear to me because of the wording in the docs. For example, in Azure built-in roles, Contributor is described as a role that grants "full access to manage all resources", which in my interpretation would make it more than a role definition (i.e., role definition + scope), but its JSON representation makes it clear: all these are pure roles and the only mention of scopes relates to a restriction of what scopes can be assigned to them during role assignment (see AssignableScopes).

[2]: Yeah, this one was a bit forced...

Harter