Hello and welcome back. A tool that goes hand-in-hand with Azure active directory is Azure role-based access control, or RBAC. Azure RBAC is used to manage who has access to what resources and to manage what those users can do with those resources. It’s an authorization system that is built upon Azure resource manager, and it offers fine-grained access management to your Azure resources.

Azure RBAC relies on role assignments for access control. Each role assignment consists of three parts, a security principal, a role definition, and a scope.

The Security principal is essentially an object that represents either a user, a group, a service principal, or a managed identity that requires access to resources in Microsoft Azure. 

The role definition is essentially a collection of permissions. Role definitions are usually referred to simply as roles. A specific role will list the operations that can be performed by someone with that role. These operations include things like read, write, and delete.

Although there are many built-in roles in Azure that you can use, there are four fundamental roles available. These fundamental roles include owner, contributor, reader, and user access administrator. A person assigned the owner role has full access to all resources, including the rights to delegate access to others. A person assigned the contributor role can create and manage all kinds of Azure resources. However, a contributor cannot grant access to those resources to other users. The reader role allows you to view existing Azure resources, while the user access administrator role allows you to manage user access to your Azure resources.

In addition to the built-in roles you can also create custom roles. This allows you to tailor access to your resources in a way that best suits your organization.

A scope is a set of resources that the access you are setting up applies to. For example, you may provide access to a scope that includes a subscription or maybe a resource group or even a specific resource. A scope in Microsoft Azure can be specified at the management group level, the subscription level, the resource group level, or to specific resources. Because scopes are structured in parent-child relationship, access that is granted at the parent scope level will be inherited by the child scopes.

The process that Azure RBAC uses to determine if a user has access to a specific resource is pretty straightforward. First, the user requesting the access acquires a token from Azure resource manager. This token includes any group memberships for the user. 

Next, the user makes a rest API call to Azure resource manager with the attached token.

What Azure resource manager will do next is retrieve all the role assignments and deny assignments for the resource that the user is trying to access. Azure resource manager will then narrow those role assignments down to only those that apply to the user or to groups that the user is a member of. It will also determine which roles have been assigned to the user for the resource being accessed.

Next, Azure resource manager will determine whether or not the requested action in the API call is allowed by the role that the user has for the specific resource being accessed.

Assuming the user is assigned a role that allows the action being requested at the requested scope, access is granted. Otherwise, access is blocked.

Azure RBAC is free and is included with all Azure subscriptions.

To learn more about Azure RBAC, visit the URL that you see on your screen.