Azure Identity and Access Management

Knowing who someone is (authentication) is only half the story. The other half is determining what they are allowed to do (authorization). Azure Identity and Access Management (IAM), implemented through Azure Role-Based Access Control (RBAC), is the system that controls which users, groups, and services can perform which actions on which Azure resources.

What is Role-Based Access Control (RBAC)?

Azure RBAC is an authorization system that grants access to Azure resources based on roles. Instead of giving every user full access to everything, RBAC follows the principle of least privilege — each person or service gets only the minimum access needed to do their job and nothing more.

Real-World Analogy

Think of a hospital. A doctor can access patient records and prescribe medication. A nurse can access patient records but cannot prescribe. A receptionist can schedule appointments but cannot access medical records at all. Each role has specific permissions based on job requirements. Azure RBAC works exactly the same way for cloud resources.

Three Core Elements of Azure RBAC

Diagram – RBAC Assignment

  Security Principal    Role Definition      Scope
  ┌─────────────┐      ┌───────────────┐    ┌───────────────────────┐
  │  WHO        │  +   │  WHAT         │ +  │  WHERE                │
  │             │      │               │    │                       │
  │ • User      │      │ • Owner       │    │ • Management Group    │
  │ • Group     │      │ • Contributor │    │ • Subscription        │
  │ • Service   │      │ • Reader      │    │ • Resource Group      │
  │   Principal │      │ • Custom Role │    │ • Individual Resource │
  └─────────────┘      └───────────────┘    └───────────────────────┘
         │                    │                        │
         └────────────────────┴────────────────────────┘
                              │
                         Role Assignment
                   (User X can do Role Y on Scope Z)

Security Principal (WHO)

The entity that needs access. This can be a user, a group of users, a service principal (application identity), or a managed identity.

Role Definition (WHAT)

A collection of permissions that defines what actions are allowed or denied. For example, the "Reader" role definition includes the permission to view resources but not modify them.

Scope (WHERE)

The boundary where the role assignment applies. Azure RBAC uses a hierarchical scope model:

  Management Group  (broadest scope)
       │
       ▼
  Subscription
       │
       ▼
  Resource Group
       │
       ▼
  Individual Resource  (narrowest scope)

  A role assigned at a higher scope is inherited by all resources below it.
  Example: Reader role at Subscription level = Reader on ALL resource groups
  and resources within that subscription.

Built-in Roles

Azure provides over 100 built-in roles. The four fundamental roles that apply to all resource types are:

Service-Specific Roles

Beyond the fundamental four, Azure provides many specialized built-in roles:

Custom Roles

When no built-in role perfectly matches the requirement, a custom role can be created. Custom roles are defined using JSON and list specific allowed or denied actions.

Example: Custom Role – Virtual Machine Starter

  {
    "Name": "Virtual Machine Starter",
    "Description": "Can start and stop VMs but cannot create or delete them",
    "Actions": [
      "Microsoft.Compute/virtualMachines/start/action",
      "Microsoft.Compute/virtualMachines/deallocate/action",
      "Microsoft.Compute/virtualMachines/read"
    ],
    "NotActions": [],
    "AssignableScopes": [
      "/subscriptions/your-subscription-id"
    ]
  }

How to Assign a Role (Step-by-Step)

1. Open the Azure Portal and navigate to the resource, resource group, or subscription.
2. Click Access control (IAM) in the left menu.
3. Click Add → Add role assignment.
4. Select the Role (e.g., Reader).
5. Select the Members (user, group, or service principal).
6. Click Review + assign.

The assignment takes effect almost immediately. The user can now access the resource with the permissions defined by the assigned role.

Privileged Identity Management (PIM)

PIM is an Azure AD Premium P2 feature that manages, controls, and monitors access to high-privileged roles. Instead of having permanent admin access, PIM enables just-in-time (JIT) access — users request elevated permissions when needed, the request is approved, access is granted for a limited time, and then it automatically expires.

PIM Workflow

  Normal State: User has Reader role (no admin access)
  │
  ├── User requests: "Need Contributor access for the next 4 hours"
  │
  ├── Manager receives approval request notification
  │
  ├── Manager approves the request
  │
  ├── PIM grants Contributor role for exactly 4 hours
  │   (All actions during this period are logged and audited)
  │
  └── After 4 hours: Contributor role is automatically removed
      User returns to Reader role

DENY Assignments

In addition to role assignments that allow actions, Azure supports deny assignments that block specific actions even if a role assignment elsewhere would allow them. Deny assignments take precedence over role assignments. They are primarily used by Azure Blueprints and Managed Applications to lock down certain configurations.

Key Takeaways

• Azure RBAC is the authorization system that controls who can do what on which Azure resources.
• Every role assignment has three parts: a security principal (who), a role definition (what), and a scope (where).
• Permissions are inherited — a role assigned at a resource group applies to all resources within it.
• The four fundamental roles are Owner, Contributor, Reader, and User Access Administrator.
• Custom roles can be created using JSON to define specific allowed actions when no built-in role fits.
• Privileged Identity Management (PIM) enables just-in-time access for sensitive roles to reduce permanent privilege exposure.