SA1.5 Authentication and Permissions

Pattern 1: Managed identity for Microsoft APIs

Managed identity solves the credential management problem. Instead of creating a service account with a password that expires, embedding a client secret that leaks, or hardcoding an API key that appears in version control — you enable a system-assigned identity on the Logic App and Azure handles credential issuance, rotation, and revocation automatically.

When your playbook calls Microsoft Graph to query a user’s risk level, the HTTP action authenticates using the managed identity. Azure intercepts the request, obtains an OAuth token for the identity, attaches it to the API call, and the Graph API validates the token. The entire flow happens without credentials appearing anywhere — not in the Logic App definition, not in the run history, not in the logs.

Enabling managed identity. Navigate to your Logic App → Settings → Identity → System assigned → Status: On → Save. Azure creates the identity and shows the Object ID. You need this ID for permission grants.

Granting Azure RBAC roles. For Sentinel and Log Analytics operations, the managed identity needs RBAC roles at the workspace level. Navigate to Sentinel workspace → Access control (IAM) → Add role assignment → select role → select the Logic App’s managed identity as member.

Enrichment playbooks need two roles: Microsoft Sentinel Responder (read incidents, add comments, change properties) and Log Analytics Reader (run KQL queries). These roles provide the minimum access for Tier 1 operations.

Granting Microsoft Graph permissions. This is where most builders get stuck. The Azure portal does not support granting application permissions to managed identities — only to app registrations. You must use PowerShell.

The process using Microsoft Graph PowerShell SDK:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

# Install the module if not present
Install-Module Microsoft.Graph -Scope CurrentUser

# Connect with admin permissions
Connect-MgGraph -Scopes "AppRoleAssignment.ReadWrite.All"

# Get the managed identity's service principal
$MI = Get-MgServicePrincipal -Filter "displayName eq 'SA-Playbook-Enrichment-First'"

# Get the Microsoft Graph service principal (always the same appId)
$Graph = Get-MgServicePrincipal -Filter "appId eq '00000003-0000-0000-c000-000000000000'"

# Find the specific permission
$UserRead = $Graph.AppRoles | Where-Object { $_.Value -eq "User.Read.All" }
$RiskyUser = $Graph.AppRoles | Where-Object { $_.Value -eq "IdentityRiskyUser.Read.All" }

# Grant User.Read.All
New-MgServicePrincipalAppRoleAssignment `
    -ServicePrincipalId $MI.Id `
    -PrincipalId $MI.Id `
    -ResourceId $Graph.Id `
    -AppRoleId $UserRead.Id

# Grant IdentityRiskyUser.Read.All
New-MgServicePrincipalAppRoleAssignment `
    -ServicePrincipalId $MI.Id `
    -PrincipalId $MI.Id `
    -ResourceId $Graph.Id `
    -AppRoleId $RiskyUser.Id

After running these commands, the managed identity can call Graph endpoints that require these permissions. The permissions take effect within minutes — no Logic App restart required.

Using managed identity in the Logic App. In the HTTP action, set Authentication type to “Managed Identity,” set Managed Identity to “System-assigned,” and set Audience to https://graph.microsoft.com. For Log Analytics queries, the “Run query and list results” action handles authentication through the connector configuration — select “Connect with managed identity” during setup.

Pattern 2: Key Vault for API keys

Third-party APIs like VirusTotal, AbuseIPDB, and Shodan use API keys. These keys must never appear in your Logic App definition. Anyone with read access to the Logic App (Contributor role on the resource group) can view the full JSON definition, including any hardcoded values.

Setting up Key Vault. Create an Azure Key Vault (portal.azure.com → Create resource → Key Vault). Use the same resource group as your Logic Apps. Enable RBAC authorization model (not the legacy access policy model).

Storing secrets. Navigate to Key Vault → Objects → Secrets → Generate/Import. Create one secret per API key: “VirusTotal-API-Key” → paste the key → Create. Repeat for AbuseIPDB, Shodan, and any other external API.

Granting access. The Logic App’s managed identity needs the “Key Vault Secrets User” role on the Key Vault. Navigate to Key Vault → Access control (IAM) → Add role assignment → Key Vault Secrets User → select the Logic App’s managed identity.

Reading secrets in the Logic App. Add an action: “Azure Key Vault — Get secret.” Select the Key Vault name and the secret name (“VirusTotal-API-Key”). The action returns the secret value at runtime. Reference the output in subsequent HTTP actions:

In the HTTP action headers, add: x-apikey → dynamic content → “Get secret” → value.

The API key is read from Key Vault each time the playbook runs. If you rotate the key (generate a new one in VirusTotal, update the Key Vault secret), the Logic App uses the new key on the next run with no playbook modification.

Pattern 3: Connector-managed authentication

Some Logic App connectors handle authentication through their own connection mechanism. The Teams connector, Outlook connector, and SharePoint connector use delegated (user-context) authentication — when you create the connection, you sign in with your account, and the connector uses your identity for subsequent actions.

This is acceptable for notification actions (posting to Teams, sending email) but has an operational risk: the connection is tied to a specific user account. If that user’s password changes, MFA re-enrollment is required, or the account is disabled, the connection breaks and the playbook fails.

The mitigation: create connections using a dedicated service account (e.g., soc-automation@northgateeng.com) that is excluded from password expiration policies, has a dedicated MFA method, and is not used for interactive sign-in. Document the service account in the playbook runbook and include connection refresh in the quarterly maintenance checklist.

For Microsoft Graph operations, always prefer managed identity over connector-managed auth. Managed identity uses application permissions (no user context required) and does not depend on any individual user account.

Least privilege — the design principle

Every permission beyond the minimum required is attack surface. An enrichment playbook with Directory.ReadWrite.All (granted “just in case”) gives a compromised managed identity the ability to create admin accounts, modify group memberships, and change conditional access policies. An enrichment playbook with User.Read.All limits the compromise to reading user properties — visibility without modification capability.

The permission matrix by playbook type is not a guideline — it is the specification. When you build each playbook in this course, the sub specifies the exact permissions required. Do not add permissions that are not listed. If a future playbook enhancement requires a new permission, grant it explicitly at that time — do not pre-grant permissions for features you have not built yet.

Quarterly permission audit. Every 90 days, review all managed identity permissions. For each Logic App, list its granted permissions and compare against the actions the playbook currently uses. If a permission was granted during development but the corresponding action was removed in a later revision, remove the permission. The command to list all permissions:

1
2
3
4

$MI = Get-MgServicePrincipal -Filter "displayName eq 'SA-Playbook-Enrichment-First'"
Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $MI.Id |
    Select-Object ResourceDisplayName, AppRoleId |
    Format-Table -AutoSize