• Authentication Services in Azure
• Identity Access management
• Implementing RBAC

What is IAM in Azure?

IAM stands for Identity and Access Management. In Azure, IAM is a framework for managing digital identities and access to resources. It helps control who can access what resources and under what conditions, ensuring security and compliance.

Key Concepts of IAM in Azure

1. Identities: Represents users, groups, applications, or other entities that need access to Azure resources.
2. Roles: Defines a set of permissions that can be assigned to identities. Azure provides built-in roles, and you can also create custom roles.
3. Role Assignments: The association between a role and an identity, specifying which role applies to which identity for which resource.

What is Authentication and Authorization?

• Authentication: The process of verifying the identity of a user or service. It ensures that the entity is who it claims to be.
• Authorization: The process of determining what actions an authenticated entity is allowed to perform. It ensures that the entity has the right permissions to access resources.

Step-by-Step Explanation with Examples

Step 1: Authentication

1. User Signs In:
   • A user attempts to sign in to the Azure portal.
   • They provide their credentials (username and password).
   • Example: John, an employee at Contoso, enters his corporate email and password.
2. Identity Verification:
   • Azure Active Directory (Azure AD) verifies the credentials.
   • If using multi-factor authentication (MFA), an additional verification step (e.g., a text message code) is required.
   • Example: After entering his password, John receives a verification code on his phone, which he enters to complete the sign-in process.

Step 2: Authorization

1. Role Assignment:
   • John is assigned to the “Contributor” role for a specific resource group.
   • This role assignment is made by an admin or through an automated process.
   • Example: John’s manager assigns him the “Contributor” role for the “MarketingResources” resource group.
2. Access Control:
   • When John tries to access a resource in the “MarketingResources” resource group, Azure checks his role assignments.
   • The “Contributor” role allows him to create, update, and delete resources within the resource group but not assign roles or manage access.
   • Example: John can create a new virtual machine in the “MarketingResources” resource group but cannot assign roles to other users.

Step 3: Managing Access with IAM

1. Creating Custom Roles:
   • If built-in roles do not meet specific needs, custom roles can be created.
   • A custom role includes a set of permissions defined in JSON format.
   • Example: Creating a custom role “MarketingVMManager” that allows starting and stopping VMs but not creating or deleting them.

{
  "Name": "MarketingVMManager",
  "IsCustom": true,
  "Description": "Can start and stop VMs in the marketing resource group",
  "Actions": [
    "Microsoft.Compute/virtualMachines/start/action",
    "Microsoft.Compute/virtualMachines/deallocate/action"
  ],
  "NotActions": [
    "Microsoft.Compute/virtualMachines/delete"
  ],
  "AssignableScopes": [
    "/subscriptions/{subscription-id}/resourceGroups/MarketingResources"
  ]
}

Assigning Roles to Users:

• Assign the custom role to a user or group.
• Example: Assign the “MarketingVMManager” role to the “MarketingTeam” group.

Reviewing and Auditing Access:

• Regularly review role assignments and access permissions.
• Use Azure Activity Logs and Azure AD logs to audit access and changes.
• Example: An admin reviews the role assignments for the “MarketingResources” resource group to ensure only authorized users have access.

In Azure IAM:

• Authentication verifies the identity of users and services.
• Authorization determines what authenticated users and services can do.
• Roles and Role Assignments help manage permissions in a structured and secure manner.

Users

Users are individual accounts that can log in and access Azure services.

Example:

• John Doe: An employee with an Azure account john.doe@contoso.com.

Groups

Groups are collections of users. Permissions assigned to a group apply to all members of the group.

Example:

• Marketing Team Group: A group that includes John Doe and Jane Smith.

Roles

Roles define a set of permissions that specify what actions can be performed on Azure resources.

Example:

• Reader Role: Can view all resources but cannot make changes.
• Contributor Role: Can create and manage all types of Azure resources but cannot manage access.
• Custom Role: Allows specific actions like starting and stopping virtual machines but not creating or deleting them.

Putting It All Together

Scenario: Managing Access to an Azure Resource Group

1. Creating Users:
   • John Doe (john.doe@contoso.com)
   • Jane Smith (jane.smith@contoso.com)
2. Creating a Group:
   • MarketingTeam: A group that includes John Doe and Jane Smith.
3. Assigning Roles:Built-in Roles:
   • Reader: Assign this role to the MarketingTeam group so that all members can view resources in the “MarketingResources” resource group.
     • Example: John and Jane can both view the resources but cannot make changes.
   • Contributor: Assign this role to John Doe directly so he can create and manage resources in the “MarketingResources” resource group.
     • Example: John can create new virtual machines, delete existing ones, and modify resources.
   Custom Role:
   • MarketingVMManager: A custom role that allows starting and stopping VMs but not creating or deleting them.
     • Example: Jane Smith can start and stop virtual machines but cannot create or delete them.

Summary

• Users: John Doe and Jane Smith each have their own Azure accounts.
• Groups: The MarketingTeam group includes both John and Jane.
• Roles:
  • The Reader role allows viewing resources.
  • The Contributor role allows full management of resources.
  • A custom role like MarketingVMManager allows specific actions.

Practical Example

1. User John Doe:
   • Belongs to the MarketingTeam group.
   • Has the Contributor role for the “MarketingResources” resource group.
   • Permissions: Can view, create, update, and delete resources in the “MarketingResources” resource group.
2. User Jane Smith:
   • Belongs to the MarketingTeam group.
   • Has a custom role (MarketingVMManager) for the “MarketingResources” resource group.
   • Permissions: Can view all resources and start/stop VMs but cannot create or delete resources.
3. MarketingTeam Group:
   • Includes John Doe and Jane Smith.
   • Assigned the Reader role for the “MarketingResources” resource group.
   • Permissions: All members can view resources in the “MarketingResources” resource group.

This setup allows you to efficiently manage access and permissions in Azure, ensuring that users have the appropriate level of access based on their roles and responsibilities.

Microsoft Entra ID

Microsoft Entra ID (formerly known as Azure Active Directory (Azure AD)) is Microsoft’s cloud-based identity and access management service. It is designed to help organizations manage and secure access to their resources, including Azure services, Office 365, and other cloud applications.

Key Features of Microsoft Entra ID

1. Single Sign-On (SSO):
   • Allows users to log in once and access multiple applications and services without needing to re-enter credentials.
2. Multi-Factor Authentication (MFA):
   • Enhances security by requiring two or more verification methods (e.g., password and a phone call or text message code).
3. Conditional Access:
   • Policies that help ensure only the right users and devices have access to your resources. For example, requiring MFA when accessing from an unknown network.
4. Identity Protection:
   • Uses machine learning to detect and respond to suspicious activities related to user identities.
5. Access Reviews:
   • Regularly review and certify access to resources, ensuring compliance and reducing the risk of excessive permissions.
6. B2B Collaboration:
   • Allows organizations to securely share their applications and services with guest users from any other organization.
7. B2C Authentication:
   • Enables businesses to provide identity and access management for their customers.
8. Integration with Other Microsoft Services:
   • Seamlessly integrates with other Microsoft services like Office 365, Dynamics 365, and the Azure platform.

Example Scenarios

Scenario 1: Single Sign-On (SSO)

Description:

• Employees can use their Microsoft Entra ID credentials to access multiple applications, including Office 365, Salesforce, and custom apps, without logging in separately to each application.

Example:

• John Doe logs into his Microsoft Entra ID account in the morning. He can then access his email on Office 365, the company’s Salesforce account, and an internal HR application without needing to log in again for each service.

Scenario 2: Multi-Factor Authentication (MFA)

Description:

• Enhances security by requiring an additional form of verification besides the password.

Example:

• Jane Smith attempts to log into the company’s portal from a new device. After entering her password, she receives a text message with a verification code on her phone, which she must enter to complete the login process.

Scenario 3: Conditional Access

Description:

• Conditional access policies can enforce access rules based on various conditions like user location, device state, and risk level.

Example:

• The company implements a policy that requires users to perform MFA if they are accessing resources from outside the corporate network.

Scenario 4: Identity Protection

Description:

• Uses machine learning to detect and respond to suspicious activities.

Example:

• Anomalous sign-in activities such as impossible travel (logging in from two different countries within a short time span) trigger alerts and require further verification.

Microsoft Entra ID (formerly Azure AD) is a comprehensive identity and access management service that helps organizations manage user identities, secure access to applications, and enhance security through advanced features like SSO, MFA, and conditional access. It is a crucial component for modern organizations to ensure secure and efficient access to their digital resources.

Service Principal and Managed Identity in Azure: In-Depth Explanation

In Azure, Service Principal and Managed Identity are concepts related to identity and access management for applications and services. These features help secure and manage the access of applications to resources without the need for human intervention.

Service Principal

A Service Principal is an identity created for use with applications, hosted services, and automated tools to access Azure resources. It is essentially an application within Azure Active Directory (Azure AD).

Key Concepts:

1. Application Object: A global representation of the application in Azure AD.
2. Service Principal Object: A local representation of the application within a specific tenant. It’s what is used to assign permissions to the application.

Managed Identity

Managed Identity is a feature of Azure Active Directory that provides an automatically managed identity for applications to use when connecting to resources. Managed Identities eliminate the need for developers to manage credentials.

Key Concepts:

1. System-Assigned Managed Identity: Tied to a specific Azure resource and automatically managed by Azure. It is enabled directly on the Azure service instance.
2. User-Assigned Managed Identity: Created as a standalone Azure resource and can be assigned to one or more Azure service instances.

Service Principals and Managed Identities are critical for secure, automated access to Azure resources by applications and services.

• Service Principals are flexible and can be used across tenants, providing granular control over permissions and access.
• Managed Identities simplify credential management and improve security by integrating seamlessly with Azure services, making them ideal for applications running within Azure.

Differences Between Managed Identities and Service Principals

1. Management:
   • Managed Identities: Automatically managed by Azure, reducing the need for manual credential management. Ideal for scenarios where resources within Azure need to interact securely.
   • Service Principals: Manually created and managed, requiring handling of client secrets or certificates. Offers flexibility and is suitable for cross-tenant scenarios.
2. Lifecycle:
   • Managed Identities: System-assigned managed identities are tied to the lifecycle of the resource. When the resource is deleted, the identity is also removed. User-assigned managed identities have their own lifecycle independent of any resource.
   • Service Principals: Have an independent lifecycle and must be managed separately, including the rotation of secrets or certificates.
3. Security:
   • Managed Identities: More secure as credentials are not exposed in the code. They are managed by Azure, which takes care of rotation and protection.
   • Service Principals: Require explicit management of secrets or certificates, which can be prone to mismanagement if not handled correctly.
4. Usage Scenarios:
   • Managed Identities: Best for scenarios within Azure, where resources like VMs, App Services, and Function Apps need to access other Azure services.
   • Service Principals: Suitable for applications or services that run outside of Azure or need cross-tenant access.

Managed Identities

Managed Identities are Azure-managed identities that allow Azure services to authenticate to other Azure services without storing credentials in your code.

Key Points:

1. Automatic Management: Azure creates and manages these identities, so you don’t have to worry about credentials.
2. Types:
   • System-Assigned: Tied to a specific Azure resource (like a Virtual Machine). If the resource is deleted, the identity is deleted too.
   • User-Assigned: Created as a standalone resource that can be assigned to multiple Azure services.

Simple Example:

Scenario: A Virtual Machine (VM) needs to access a Storage Account.

1. Enable Managed Identity on the VM:
   • In the Azure portal, go to your VM.
   • Enable the “System-Assigned Managed Identity” option.

1. Assign Permissions to the Managed Identity:
   • Go to your Storage Account.
   • Add a role assignment for the VM’s managed identity with the required permissions (e.g., “Storage Blob Data Contributor”).
2. Access Storage Account from the VM:
   • Inside your VM, use Azure SDK to access the Storage Account without hardcoding credentials.

from azure.identity import DefaultAzureCredential
from azure.storage.blob import BlobServiceClient

credential = DefaultAzureCredential()
blob_service_client = BlobServiceClient(account_url="https://<storage-account-name>.blob.core.windows.net", credential=credential)
containers = blob_service_client.list_containers()
for container in containers:
    print(container.name)

or

Commands to access Blob from the Virtual Machine

Fetch the access token

access_token=$(curl 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https%3A%2F%2Fstorage.azure.com%2F' -H Metadata:true | jq -r '.access_token')

Access the blob from Virtual Machine

storage_account_name=”” container_name=”” blob_name=””

curl "https://$storage_account_name.blob.core.windows.net/$container_name/$blob_name" -H "x-ms-version: 2017-11-09" -H "Authorization: Bearer $access_token"

Service Principals

Service Principals are identities created for applications to access Azure resources. They are like user accounts, but for applications.

Key Points:

1. Manual Management: You need to create and manage the credentials (client ID and secret or certificate).
2. Flexible Use: Can be used for applications running outside Azure or for cross-tenant access.

Simple Example:

Scenario: An application needs to access an Azure SQL Database.

Create a Service Principal:

• Use Azure CLI to create a service principal.

az ad sp create-for-rbac --name myServicePrincipal

Get Application ID and Secret:

• Note down the appId and password provided by the command.

Assign SQL Database Permissions to the Service Principal:

• Connect to your SQL Database and create a user for the service principal, then assign the necessary roles.

CREATE USER [myServicePrincipal] FROM EXTERNAL PROVIDER;
EXEC sp_addrolemember 'db_datareader', 'myServicePrincipal';
EXEC sp_addrolemember 'db_datawriter', 'myServicePrincipal';

Access SQL Database Using the Service Principal:

• Use the service principal credentials in your application to connect to the SQL Database.

import pyodbc

conn = pyodbc.connect(
    'DRIVER={ODBC Driver 17 for SQL Server};SERVER=tcp:<sql-server-name>.database.windows.net,1433;DATABASE=<database-name>;UID=<application-id>;PWD=<client-secret>'
)
cursor = conn.cursor()
cursor.execute("SELECT TOP 10 * FROM myTable")
for row in cursor:
    print(row)

Differences in Simple Terms

1. Managed Identities:
   • Automatic: Azure manages the identity and credentials.
   • No Credential Handling: You don’t need to store or rotate secrets.
   • Usage: Ideal for Azure services needing to access other Azure services.
2. Service Principals:
   • Manual: You create and manage the credentials.
   • Credential Handling: You need to store and manage secrets or certificates.
   • Usage: Suitable for applications running outside Azure or for scenarios requiring more control.

Summary

• Managed Identities: Easy and secure way for Azure services to access other Azure resources without manual credential management.
• Service Principals: Flexible identity option for applications, requiring manual management of credentials but usable in a broader range of scenarios.