3.1.5. Implement Authorization

First Principle: Authorization ensures that only permitted identities can access or modify resources within Azure applications. Its core purpose is to enforce what actions an authenticated user or service can perform, serving as a critical security layer.

What It Is: "Authorization" determines what actions an authenticated user or service can perform within Azure applications. It is a critical security layer, ensuring only permitted identities can access or modify resources.

Visual: "Azure Authorization Mechanisms"

Loading diagram...

• "Role-Based Access Control (RBAC)": Azure’s primary system for managing access to resources. "RBAC" is built on three main components:

  • "Security Principal": The identity (user, group, service principal, or managed identity) requesting access.
  • "Role Definition": A set of permissions (e.g., Reader, Contributor, Owner) that describe allowed actions.
  • "Scope": The range of resources the role applies to ("management group", "subscription", "resource group", or resource). "RBAC" is best for broad, organization-level access management. For example, you can grant a team Contributor rights to a "resource group", allowing them to manage all resources within that group.

• "Shared Access Signatures (SAS)": Provide a way to grant limited, time-bound access to "Azure Storage resources" (blobs, queues, tables, files) without sharing "storage account keys". A "SAS token" includes:

  • "URI": The "resource address" with the "SAS token" appended.
  • "Signed start/expiry": The time window when access is valid.
  • "Permissions": Specific allowed operations (read, write, delete, etc.).
  • "IP address & protocol": Optional restrictions for added security. "SAS" is ideal for scenarios requiring granular, temporary access—such as allowing a client to upload a file to a "storage container" for a short period.

Choosing the right strategy:

• Use "RBAC" for managing access to Azure resources at scale.
• Use "SAS" for delegating temporary, specific access to "storage resources".

Scenario: You have a new application that needs to securely upload large files directly from client-side code to an Azure Blob Storage container for a limited time. You also need to manage developer access to various Azure resources (VMs, databases) within a resource group.

Reflection Question: How does strategically choosing between "Role-Based Access Control (RBAC)" (for managing access to Azure resources) and "Shared Access Signatures (SAS)" (for granular, time-limited storage access) fundamentally enable robust authorization, ensuring only permitted identities can access or modify resources in Azure applications?