Module: Design Identity, Governance, and Monitoring Solutions

Section: Design Authentication and Authorization Solutions

Lesson Title: Microsoft Entra ID for Solution Architects

---

1. Introduction: The Foundation of Modern Identity

In today's cloud-first world, identity is the new perimeter. Traditional on-premises Active Directory (AD) served us well for decades, but the proliferation of SaaS applications, mobile devices, and distributed workforces demands a more flexible, secure, and scalable identity solution. This is where Microsoft Entra ID (formerly Azure Active Directory) steps in.

Microsoft Entra ID is a comprehensive, cloud-based identity and access management (IAM) service that helps your employees sign in and access internal and external resources. For solution architects, understanding Entra ID is paramount because it forms the backbone of authentication and authorization for:

• Microsoft 365 applications (e.g., Exchange Online, SharePoint Online, Teams)
• Azure portal and Azure resources
• Thousands of SaaS applications (e.g., Salesforce, ServiceNow, Workday)
• Custom applications built on Azure or other platforms
• On-premises applications (via Entra ID Application Proxy)

Why is this crucial for Solution Architects? As a solution architect, you are responsible for designing secure, scalable, and manageable systems. Entra ID provides the core identity services that enable:

• Single Sign-On (SSO): Streamlining user experience and reducing password fatigue.
• Enhanced Security: Multi-Factor Authentication (MFA), Conditional Access policies, and Identity Protection.
• Centralized Management: A single pane of glass for user identities, groups, and application access.
• Integration Capabilities: Seamlessly connecting diverse applications and services.
• Compliance: Meeting regulatory requirements for access control and auditing.

Designing solutions without a deep understanding of Entra ID would be like building a house without a foundation – it might stand for a while, but it will eventually crumble under pressure.

---

2. Detailed Explanation with Practical Examples

Let's break down the core components and capabilities of Microsoft Entra ID relevant to solution architects.

2.1. Core Concepts

• Tenant: Your dedicated instance of Microsoft Entra ID. It's a logically isolated container for your organization's objects (users, groups, apps). Every Azure subscription is associated with an Entra ID tenant.
  • Example: When you sign up for an Azure subscription or Microsoft 365, a new Entra ID tenant is provisioned for your organization (e.g., contoso.onmicrosoft.com).
• Users and Groups: Standard identity objects. Users are individuals, and groups are collections of users, often used for assigning permissions efficiently.
  • Example: Create a security group Developers and assign it access to a specific Azure resource group or an application role.
• Application Registration: Represents an application (web app, API, SPA, mobile app) that needs to interact with Entra ID for authentication/authorization. It defines app properties, permissions, and redirect URIs.
  • Example: Register your custom web application in Entra ID to enable users to sign in using their Entra ID credentials.
• Service Principal: An instance of an application registration within a specific tenant. For single-tenant apps, the app registration and service principal often seem like the same thing. For multi-tenant apps, there's one app registration in the publisher's tenant, and a service principal in each tenant where it's used.
  • Example: When a user in contoso.onmicrosoft.com consents to use a multi-tenant SaaS application (e.g., Salesforce), a service principal for Salesforce is created in the Contoso tenant, representing Salesforce's presence there.
• Managed Identities: Entra ID identities automatically managed by Azure for Azure resources. They eliminate the need for developers to manage credentials.
  • Example: An Azure Function needs to read secrets from Azure Key Vault. Instead of managing a service principal's client secret, assign a system-assigned or user-assigned managed identity to the Azure Function and grant that identity Key Vault Secrets Reader permissions.

2.2. Authentication Methods

Entra ID supports various authentication methods, focusing on security and user experience.

• Single Sign-On (SSO): Users sign in once with one set of credentials to access multiple applications.
  • Implementation: Achieved through protocols like OpenID Connect (OIDC), OAuth 2.0, and SAML 2.0.
• Multi-Factor Authentication (MFA): Requires users to provide two or more verification factors to gain access.
  • Example: User enters password, then approves a notification on their Microsoft Authenticator app.
• Conditional Access: A powerful policy engine that evaluates conditions (user, location, device state, application, sign-in risk) to make access decisions.
  • Example: Block access to sensitive applications if the user is signing in from an unmanaged device or an unfamiliar location. Require MFA for administrators accessing the Azure portal.
• Passwordless Authentication: Eliminates passwords entirely, using methods like FIDO2 security keys, Windows Hello for Business, or Microsoft Authenticator.
  • Architectural Benefit: Reduces phishing risks and improves user experience.

2.3. Authorization

Once authenticated, Entra ID determines what resources a user or application can access.

• Azure Role-Based Access Control (RBAC): Authorizes users and applications to perform actions on Azure resources.
  • Example: Grant the Contributor role to the Developers group for a specific resource group, allowing them to deploy and manage resources within it.
• Application Permissions (App-only): Permissions granted directly to an application (service principal) to access resources without a signed-in user. Ideal for daemon services, background jobs.
  • Example: A backend service needs to read all users from Microsoft Graph. It requests User.Read.All application permission.
• Delegated Permissions: Permissions granted to an application to act on behalf of a signed-in user. The application's effective permissions are the intersection of its requested permissions and the user's permissions.
  • Example: A web app needs to read the signed-in user's profile from Microsoft Graph. It requests User.Read delegated permission. If the user has permission to read their own profile, the app can proceed.
• Custom Application Roles: Define specific roles within your application and map them to Entra ID users or groups. Entra ID then issues these roles as claims in the access token.
  • Example: Your custom HR application defines HR Admin and HR Employee roles. You map the Entra ID group HR Admins to the HR Admin application role.

2.4. Integration Patterns

• Hybrid Identity: Synchronizing on-premises Active Directory identities with Entra ID using Entra ID Connect.
  • Architectural Decision: Choose between Password Hash Synchronization (PHS), Pass-Through Authentication (PTA), or Federated Authentication (AD FS). PHS is generally recommended for simplicity and resilience.
• SaaS Application Integration: Connecting third-party SaaS applications (e.g., Salesforce, ServiceNow) for SSO and user provisioning.
  • Mechanism: Often uses SAML 2.0 or OpenID Connect. Entra ID can also provision users to these apps via SCIM.
• Custom Application Integration: Using the Microsoft Authentication Library (MSAL) in your applications (web, API, SPA, mobile, desktop) to interact with Entra ID.
  • Example: A React SPA uses MSAL.js to get an access token for a custom backend API, which then validates the token and calls Microsoft Graph.

---

3. Relevant Code Snippets

3.1. Azure CLI: Registering an Application and Assigning API Permissions

This example registers a web application and grants it delegated permissions to Microsoft Graph.

# 1. Register a new application
APP_NAME="MyWebApp-EntraID-Demo"
REPLY_URL="http://localhost:3000/auth/callback" # Your app's redirect URI

APP_REG=$(az ad app create --display-name "$APP_NAME" \
                           --sign-in-audience AzureADMyOrg \
                           --web-redirect-uris "$REPLY_URL" \
                           --query "{id:id, appId:appId}" -o json)

APP_ID=$(echo $APP_REG | jq -r .appId)
OBJECT_ID=$(echo $APP_REG | jq -r .id)

echo "Application registered:"
echo "  App ID: $APP_ID"
echo "  Object ID: $OBJECT_ID"

# 2. Create a service principal for the application
# This is often automatically done, but good to know how to explicitly create
SP_ID=$(az ad sp create --id "$APP_ID" --query "id" -o tsv)
echo "Service Principal ID: $SP_ID"

# 3. Grant delegated permissions to Microsoft Graph (e.g., User.Read)
# Get the object ID for Microsoft Graph (well-known app)
GRAPH_SP_ID=$(az ad sp list --display-name "Microsoft Graph" --query "[0].id" -o tsv)

# Define the permission you want to grant (User.Read)
# Find the ID of the User.Read permission for Microsoft Graph
USER_READ_PERMISSION_ID=$(az ad sp show --id "$GRAPH_SP_ID" --query "oauth2Permissions[?value=='User.Read'].id" -o tsv)

# Grant the permission
az ad app permission add --id "$APP_ID" --api "$GRAPH_SP_ID" --api-permissions "$USER_READ_PERMISSION_ID=Scope"

# 4. Grant admin consent for the permissions (if required and you have permissions)
# For delegated permissions, users usually consent. For app-only permissions, admin consent is often required.
# For demo purposes, we might force admin consent.
az ad app permission grant --id "$APP_ID" --api "$GRAPH_SP_ID" --scope "User.Read" --query "consentType" -o tsv

echo "Granted 'User.Read' delegated permission to Microsoft Graph for application '$APP_NAME'."

3.2. Conceptual MSAL.js snippet for a Web Application

This demonstrates how a client-side application might acquire a token using MSAL.

// Example using MSAL.js for a Single Page Application
import * as msal from "@azure/msal-browser";

const msalConfig = {
    auth: {
        clientId: "YOUR_APP_CLIENT_ID", // The App ID from your Entra ID app registration
        authority: "https://login.microsoftonline.com/YOUR_TENANT_ID", // Or "common" for multi-tenant
        redirectUri: "http://localhost:3000/auth/callback",
    },
    cache: {
        cacheLocation: "sessionStorage", // or "localStorage"
        storeAuthStateInCookie: false,
    }
};

const msalInstance = new msal.PublicClientApplication(msalConfig);

async function signIn() {
    try {
        // Option 1: Redirect to login page
        await msalInstance.loginRedirect({
            scopes: ["User.Read", "api://YOUR_API_CLIENT_ID/access_as_user"] // Scopes for Graph and your custom API
        });

        // Option 2: Popup login (less disruptive for user experience)
        // const loginResponse = await msalInstance.loginPopup({
        //     scopes: ["User.Read", "api://YOUR_API_CLIENT_ID/access_as_user"]
        // });
        // console.log("Logged in user:", loginResponse.account);

    } catch (error) {
        console.error("Login failed:", error);
    }
}

async function acquireTokenSilent() {
    const account = msalInstance.getAllAccounts()[0]; // Get the currently logged-in account
    if (!account) {
        throw new Error("No account logged in.");
    }

    const request = {
        scopes: ["User.Read", "api://YOUR_API_CLIENT_ID/access_as_user"],
        account: account
    };

    try {
        const response = await msalInstance.acquireTokenSilent(request);
        console.log("Access Token:", response.accessToken);
        return response.accessToken;
    } catch (error) {
        console.warn("Silent token acquisition failed. Acquiring token interactively...");
        // If silent acquisition fails, fallback to interactive (e.g., popup or redirect)
        const interactiveResponse = await msalInstance.acquireTokenPopup(request);
        console.log("Interactive Access Token:", interactiveResponse.accessToken);
        return interactiveResponse.accessToken;
    }
}

// Call signIn() when a user clicks a login button
// Call acquireTokenSilent() before making an API call that requires authentication

---

4. Best Practices and Common Pitfalls

4.1. Best Practices

• **Enable MFA for all users