Azure Integration Services on Andrew Wilson's Blog

Azure Logic Apps Standard | Send Custom Events to Application Insights

Tue, 03 Feb 2026 00:00:00 +0000

Introduction

When building integration workflows with Azure Logic Apps Standard, there’s often a need to track custom business events that sit between pure technical telemetry and business process monitoring. Recently, while authoring a Logic App Standard workflow, I needed to track the total number of items processed along with a breakdown of successful versus failed processing attempts.

While Logic Apps provides excellent run history and built-in diagnostics, custom events allow you to capture specific business actions and metrics that align with your reporting requirements. In this post, I’ll show you how to send custom events directly to Azure Application Insights using the ingestion endpoint from the Application Insights connection string.

The Use Case

I needed to answer questions like:

How many items were processed in total for a workflow run?
What’s the success vs. failure rate for different item types?
Can I correlate these metrics with other application telemetry?

Standard Logic Apps diagnostics don’t easily provide this level of custom business metric tracking, making Application Insights custom events the perfect solution.

Understanding the Application Insights Ingestion Endpoint

The Application Insights connection string contains several components, including the ingestion endpoint. It looks something like this:

InstrumentationKey=;IngestionEndpoint=https://.in.applicationinsights.azure.com/;LiveEndpoint=https://.livediagnostics.monitor.azure.com/;ApplicationId=

// Broken Down
//------------
InstrumentationKey=

IngestionEndpoint=https://.in.applicationinsights.azure.com/

LiveEndpoint=https://.livediagnostics.monitor.azure.com/

ApplicationId=

The Ingestion Endpoint component as the name suggests is used for the ingest of telemetry/metrics/events/etc. The component points to a regional Application Insights endpoint with the Instrumentation key supplied later in in the ingestion request for targeting your specific Application Insights instance.

The missing part to this endpoint that allows you to post your telemetry is a trailing v2/track. Combined this appears as follows: https://.in.applicationinsights.azure.com/v2/track

We’ll use the IngestionEndpoint combined with the InstrumentationKey to send custom events via HTTP requests.

Implementation

Step 1: Configure Application Insights Connection in Bicep

First, we need to extract the ingestion endpoint and instrumentation key from Application Insights and make them available to our Logic App as application settings:


resource applicationInsights 'Microsoft.Insights/components@2020-02-02' existing = {
  name: applicationInsightsName
}

resource logicAppDeployment 'Microsoft.Web/sites@2025-03-01' = {
  name: logicAppName
  location: Location
  kind: 'functionapp,workflowapp'
  properties: {
    ...
    siteConfig: {
      ...
      appSettings: [
        ...
        {
          name: 'appInsightsIngestUrl'
          value: '${split(filter(split(applicationInsights.properties.ConnectionString, ';'), val => contains(val, 'IngestionEndpoint='))[0], '=')[1]}v2/track'
        }
        {
          name: 'appInsightsKey'
          value: applicationInsights.properties.InstrumentationKey
        }
      ]
    }
  }
}

The Bicep code above parses the connection string to extract the ingestion endpoint and appends the required v2/track path. It also captures the instrumentation key needed to point to your instance.

Step 2: Create Logic App Parameters

Add parameters to your Logic App Workflow’s parameters.json file to reference these application settings:

{
    "AppInsightsIngestionUrl": {
        "type": "String",
        "value": "@appsetting('appInsightsIngestUrl')"
    },
    "AppInsightsKey": {
        "type": "String",
        "value": "@appsetting('appInsightsKey')"
    }
}

These parameters allow your workflow to access the ingestion URL and key at runtime.

Step 3: Add the Workflow Actions and Event Payload

In your Logic App workflow, use a Compose action to build the Application Insights event payload. The payload follows the Application Insights telemetry schema:

{
  "name": "Microsoft.ApplicationInsights.@{parameters('AppInsightsKey')}.Event",
  "time": "@{utcNow()}",
  "iKey": "@{parameters('AppInsightsKey')}",
  "data": {
    "baseType": "EventData",
    "baseData": {
      "ver": "2",
      "name": "LogicAppWorkflowName",
      "properties": {
        "workflowRunId": "@{workflow().run.name}",
        "ItemsProcessed": "",
        "Type1Count":  "",
        "Type1CountFailures":  "",
        "Type2Count":  "",
        "Type2CountFailures":  "",
        "Type3Count":  "",
        "Type3CountFailures":  ""
      }
    }
  }
}

Key components of the payload:

name: Event identifier following Application Insights naming convention
time: Timestamp in UTC format
iKey: Your instrumentation key
data.baseData.name: The custom event name that will appear in Application Insights
data.baseData.properties: Your custom properties containing business metrics

Step 4: Send the Event via HTTP

Add an HTTP action to send the composed payload to Application Insights:

Configure the HTTP action with:

Method: POST
URI: @{parameters('AppInsightsIngestionUrl')}
Headers: Content-Type: application/json
Body: Output from the Compose action

The HTTP action will receive a 200 OK response when the event is successfully ingested.

The response body should indicate a successful ingestion as follows:

{
    "itemsReceived": 1,
    "itemsAccepted": 1,
    "errors": []
}

Step 5: Query Your Events

After your workflow runs, navigate to Application Insights and use the following KQL query to view your custom events:

customEvents
| where name == "LogicAppWorkflowName"
| project timestamp, 
          workflowRunId = tostring(customDimensions.workflowRunId),
          itemsProcessed = toint(customDimensions.ItemsProcessed),
          type1Success = toint(customDimensions.Type1Count),
          type1Failures = toint(customDimensions.Type1CountFailures)
| order by timestamp desc

You can create custom dashboards, alerts, and reports based on these events.

Summary

By leveraging the Application Insights ingestion endpoint directly via HTTP actions, you can easily track custom business metrics from your Logic Apps Standard workflows without external dependencies. This approach lets you correlate workflow execution with wider integration components/applications and build comprehensive dashboards based on your specific use case.

Hope this helps, and keep Workflow-ing!

Azure Function Apps | OkObjectResult Returns Empty JSON After Moving to .NET 9 Isolated Worker Runtime

Wed, 03 Dec 2025 00:00:00 +0000

The Problem

I recently upgraded an Azure Function from .NET 8 to .NET 9, and at the same time migrated from the in-process worker to the isolated worker model. After the upgrade, my function that returned OkObjectResult started returning an empty JSON object {} instead of the expected data.

[Function("MyFunction")]
public IActionResult Run([HttpTrigger(AuthorizationLevel.Function,  "post")] HttpRequest req)
{
    var data = new MyResponse { Name = "Test", Value = 123 };
    return new OkObjectResult(data); // Returns {} instead of expected JSON
}

Why This Happens

There are two key changes that caused this issue:

1. In-Process to Isolated Worker Migration

The isolated worker process runs in a separate process from the Functions host. Unlike the in-process model, it doesn’t inherit any configuration or serialization settings. You’re starting with a clean slate and need to explicitly configure everything.

2. JSON Serializer Change

Starting with ASP.NET Core 3.0, Microsoft replaced Newtonsoft.Json with System.Text.Json as the default serializer. While both serialize JSON, they have different behaviors:

Newtonsoft.Json: More lenient, serializes public properties and fields
System.Text.Json: Stricter, only serializes public properties by default

When using OkObjectResult (an ASP.NET Core MVC type) in an isolated worker, you need to explicitly configure MVC services. Without this configuration, the serialization doesn’t work as expected.

The Solutions

You have two approaches to fix this, each with different trade-offs:

Option 1: Use Native Isolated Worker Types (Recommended)

Embrace the isolated worker model by using the native types designed for it:

[Function("MyFunction")]
public async Task Run([HttpTrigger(AuthorizationLevel.Function, "post")] HttpRequestData req)
{
    var data = new MyResponse { Name = "Test", Value = 123 };
    
    var response = req.CreateResponse(HttpStatusCode.OK);
    await response.WriteAsJsonAsync(data); // Uses System.Text.Json by default
    
    return response;
}

Advantages:

Better Performance: System.Text.Json is significantly faster than Newtonsoft.Json
Lower Costs: Reduced latency means less execution time, which directly reduces Azure Functions costs (billed per execution time)
Lighter Dependencies: No need for additional MVC services or packages
Future-Proof: Aligned with the modern .NET isolated worker architecture
Native Support: Uses types specifically designed for isolated workers

Disadvantages:

Requires code changes to migrate from IActionResult to HttpResponseData
May need adjustments if you rely on specific Newtonsoft.Json features

Option 2: Add MVC Services with Newtonsoft.Json (Quick Fix)

If you need a quick fix or have complex serialization requirements, you can add MVC services with Newtonsoft.Json support to your Program.cs:

using Microsoft.Extensions.Hosting;

var builder = FunctionsApplication.CreateBuilder(args);

// Add MVC services and configure Newtonsoft.Json
builder.Services.AddMvc().AddNewtonsoftJson();

builder.Build().Run();

You’ll also need to add the NuGet package:

dotnet add package Microsoft.AspNetCore.Mvc.NewtonsoftJson

Advantages:

Minimal code changes - keeps existing OkObjectResult code working
Maintains backward compatibility with Newtonsoft.Json serialization behavior
Good for quick migration when you have tight deadlines

Disadvantages:

Higher Costs: Slower serialization means longer execution time and higher Azure Functions bills
Additional Dependencies: Requires MVC framework which adds overhead
Technical Debt: You’re opting back into older patterns instead of embracing the new architecture

Which Should You Choose?

For new projects or if you can afford the refactoring time: Go with Option 1 (native types). The performance benefits and cost savings will compound over time, especially for high-traffic functions.

For quick migrations with tight deadlines: Option 2 can get you unstuck quickly, but consider it temporary. Plan to refactor to native types when time permits.

Takeaway

When migrating to .NET 9 isolated worker Functions, you’re working in a fresh environment that requires explicit configuration. While adding Newtonsoft.Json gets things working quickly, embracing the native isolated worker types with System.Text.Json offers better performance and lower costs (⚠️important factors when Azure Functions are billed per execution time). Choose the approach that balances your immediate needs with long-term architecture goals.

Hope this helps, Happy Coding.

Agent Loop | Azure Logic Apps Just Got Smarter

Wed, 21 May 2025 00:00:00 +0000

Microsoft Announcement

Microsoft has just introduced something quite revolutionary into the world of integration: Agent Loop, a new capability in Azure Logic Apps that lets you build AI-powered agents directly into your workflows. On the surface, it might seem like another incremental feature. But dig a little deeper, and the implications are huge!

Let’s break it down.

What Is Agent Loop?

Agent Loop is Microsoft’s way of embedding advanced AI decision-making into Logic Apps workflows. Think of it like adding a smart co-pilot into your integration flows, an agent that can retain context, reason over time, and take meaningful actions. It uses an LLM like Azure OpenAI under the hood, paired with a memory store that persists throughout the workflow, allowing the agent to understand, adapt, and make decisions across multiple steps.

This isn’t just a chat feature bolted onto Logic Apps. This is a new integration pattern.

Why This Matters

1. From Orchestrators to Orchestrators-With-Brains

Traditionally, Logic Apps has been a powerful tool for orchestrating workflows, but each step is stateless and reactive. With Agent Loop, Microsoft is blurring the lines between workflow automation and autonomous decision-making. Your integration logic can now evolve based on prior inputs, contextual signals, or even unstructured content.

Imagine an agent that:

Detects anomalies in data feeds and adjusts routing accordingly
Analyses unstructured text (emails, tickets, PDFs) and initiates remediation
Talks to legacy systems, interprets responses, and adapts its logic in real time

This isn’t just modernisation, it’s next-gen augmentation.

2. For BizTalk Migrations, This Changes the Equation

Many of the workflows built in BizTalk were complex not just because of their integration points, but because of the decision logic baked into orchestration layers. Until now, moving those workflows into Azure meant carefully untangling rulesets, mappings, and dependencies.

Agent Loop gives you a new option, wrap legacy logic in an AI reasoning layer, preserve existing behaviour where needed, and inject flexibility where it’s long overdue. That’s a big deal for organisations plotting their BizTalk to Azure Integration Services (AIS) migration.

3. Bridging Structured and Unstructured Worlds

In most enterprises, structured data lives in databases, but the real mess, the emails, PDFs, meeting notes, customer queries, is where value is trapped. Agent Loop lets you embed GPT-style agents that can process unstructured inputs, make sense of them, and act accordingly.

In effect, it bridges the gap between API-driven systems and human language interactions, a holy grail for integration architecture.

What Could This Enable?

Some early scenarios come to mind:

Intelligent triage: Auto-routing support tickets based on nuanced analysis, not just keywords
Contract processing: Reading legal documents and extracting obligations for ERP updates
Integration self-healing: Agents that spot failed API calls and retry or switch endpoints contextually
Customer 360 augmentation: Combining CRM data with email sentiment to tailor outreach strategies

What’s powerful here is not just the AI, it’s that the AI lives inside your governed, observable, enterprise-ready integration fabric. That’s the kind of maturity architects have been waiting for.

The Bigger Picture

This move by Microsoft is a signal, AI isn’t a separate strategy anymore, it’s becoming part of the plumbing. And for IT leaders, that means a shift in how we think about capability building.

Where before we asked, “What can be automated?”, now we ask, “What can be intelligently automated?” Where we once feared black-box AI, now we can build AI agents that live inside controlled workflows.

A Word of Caution

This is still early days. Agent Loop is in public preview, and like all AI features, there are concerns around predictability, testing, and operational risk. Governance, testing harnesses, and monitoring patterns will also need to be matured alongside adoption.

But make no mistake, this is a foundational shift.

Getting Started

Agent Loop is already available in Logic Apps Standard! Here are some Microsoft resources to help you begin:

Documentation: Explore the agent loop concepts and detailed guide with step-by-step instructions on how to configure and use Agent Loop.
Samples & Demos: Watch pre-recorded demos showcasing both conversational and autonomous agent scenarios built with Agent Loop. You’ll also get a preview of exciting features coming soon.

Final Thoughts

If you’re leading a modernisation initiative, working through a BizTalk migration, or trying to unify integration and automation under a future-proof architecture, Agent Loop deserves your attention.

It’s one of those moments where what looks like a feature is actually a new paradigm. The integration space just got a whole lot smarter,and that changes everything.

Logic App | Access Key Revocation and Regeneration

Fri, 28 Feb 2025 00:00:00 +0000

Overview

In previous articles I have subtly referenced risks and best practices regarding HTTP triggered workflows and their use of Access Keys for security, such as:

Some Potential Risks:
- If a Key is leaked, it can be used by anyone who obtains it to call your Logic App Workflow.
- If a Key has expired or been invalidated then services, applications, and or users who have not been provided a new key will cease to be able to invoke your workflow.
Some Access Key Best Practices to mitigate risks:
- Have a revocation plan - Make sure that you are prepared to respond if a Key is compromised.
- Have a rotation plan - Look to replace the Key with new ones at regular intervals.

Given the risks and best practices described, I wanted to put together a solution whereby the regeneration and issue of the access keys could be automated. This allows for keys to be regenerated on a regular schedule provided they might need to comply with security policies. Further to this, regenerating the access keys means old ones are invalidated and thus protects you in the incident were a key is compromised.

Solution

To automate the regeneration of the access keys, I am going to make use of the Azure Rest API and the following components:

Azure Key Vault - Used as secure storage for the workflow access keys.
Identity and Access Management - Services, applications, and users will gain access to the access key secrets in Key Vault through Identity and role assignment at the secret level (Principal of Least Privilege).
PowerShell Script - A script developed to invoke the Regenerate Access Key Azure Rest API.
Bicep Template - A template developed to obtain and re-issue the workflow access keys to Key Vault.
DevOps Pipeline - Using an automated pipeline to manually or on schedule invoke the PowerShell script and redeploy the Bicep template.

⚠️ Note

For automated roll out of access keys to services, applications, or users, their reference of the key vault secrets must not be directly tied to a version of the secret, rather always point to current.

Key vault reference values are cached in App Services and refetched every 24 hours.

To refetch values immediately, the following options are available:

Manually through the Portal by using the “Pull Reference Values” under “Environment Variables”.

Update the App Config. Any configuration change to the app causes an app restart and an immediate refetch of all referenced secrets.

Preferred - Pipeline powershell task after roll out that invokes a refetch.

az rest --method post --url https://management.azure.com/[Resurce ID]/config/configreferences/appsettings/refresh?api-version=2022-03-01

Script to Regenerate a Workflow Access Key

The following PowerShell script is used to Regenerate a specific Logic App Workflow Access Key. By regenerating a new key, the previous will also be invalidated.

$SubscriptionId = '{SubscriptionID}'
$ResourceGroupName = '{ResourceGroupName}'
$LogicAppName = '{Standard Logic App Name}'
$WorkflowName = '{Workflow Name}'

# Not required if automated and using as part of a DevOps pipeline.
Connect-AzAccount -Subscription $SubscriptionId 

$accessToken = Get-AzAccessToken

$request = @{
    Method = 'POST'
    Uri = "https://management.azure.com/subscriptions/$($SubscriptionId)/resourceGroups/$($ResourceGroupName)/providers/Microsoft.Web/sites/$($LogicAppName)/hostruntime/runtime/webhooks/workflow/api/management/workflows/$($WorkflowName)/regenerateAccessKey?api-version=2024-04-01"
    Body = @{
        keyType = 'Primary'
    } | ConvertTo-Json
    Headers = @{
        Authorization = "Bearer $($accessToken.Token)"
        "Content-Type" = "application/json"
    }
}

Invoke-RestMethod @request

Bicep Template to Obtain and Surface Workflow Access Keys to Key Vault

The following Bicep template is used to obtain the workflow access key and create the secret in key vault (if already deployed, then a new version).

/********************************************
Bicep Template: Workflow Access Keys Role Out
        Author: Andrew Wilson
*********************************************/

targetScope = 'resourceGroup'

// ** User Defined Types **
// ************************

@description('Object type used to identify a Workflow and Trigger')
@metadata({
  workflowName: 'The name of the workflow within your Standard Logic App.'
  workflowTrigger: 'The HTTP trigger name within the workflow'
})
@sealed()
type workflow = {
  workflowName: string
  workflowTrigger: string
}

@description('Array of Standard Logic App Workflows')
@minLength(1)
type workflowArray = workflow[]

// ** Parameters **
// ****************

@description('Name of the Logic App to place workflow(s) sig into KeyVault')
param LogicAppName string

@description('Name of the Key Vault to place secrets into')
param keyVaultName string

@description('Array of Workflows to obtain sigs from.')
param workflows workflowArray

// ** Variables **
// ***************

// ** Resources **
// ***************

@description('Retrieve the existing Logic App')
resource logicApp 'Microsoft.Web/sites@2024-04-01' existing = {
  name: LogicAppName
}

@description('Retrieve the existing Key Vault instance to store secrets')
resource keyVault 'Microsoft.KeyVault/vaults@2023-07-01' existing = {
  name: keyVaultName
}

@description('Create the Logic App workflow access key as a secret - Deployment principle requires RBAC permissions to do this')
resource vaultLogicAppKey 'Microsoft.KeyVault/vaults/secrets@2023-07-01' = [for workflow in workflows: {
  name: '${logicApp.name}-${workflow.workflowName}-sig'
  parent: keyVault
  tags: {
    ResourceType: 'LogicAppStandard'
    ResourceName: logicApp.name
  }
  properties: {
    contentType: 'string'
    value: listCallbackUrl(resourceId('Microsoft.Web/sites/hostruntime/webhooks/api/workflows/triggers', logicApp.name, 'runtime', 'workflow', 'management', workflow.workflowName, workflow.workflowTrigger), '2022-09-01').queries.sig
  }
}]

// ** Outputs **
// *************

In the instance that the access key is compromised due to a user/component/service being compromised, then the action would be two fold:

Revoke the user/component/service access to the secret in key vault.
Regenerate and issue a new access key.

Hope this helps and have fun.

Logic App | Try-Catch Pattern, Nested Scopes, And Compensating Transaction Pattern

Wed, 08 Jan 2025 00:00:00 +0000

The Try-Catch Pattern

Following the idea of defensive programming or as I like to call it for Logic Apps (being low code): defensive processing, it is considered good practice to wrap your workflows in a try-catch pattern to handle the unexpected. The pattern makes use of a mixture of Run After conditions and the Scope block.

Run After Conditions | used to define the execution order based on the state of the previous action or scope
Scope Block | provides the ability to group a series of actions. If any action within the scope fails, the whole scope will fail (unless handled via other means)

By placing your actions within a “try” scope with the assumption that each action will run after the success of the previous, if there is an action failure, the scope will fail also.

Using the Run After conditions on either a proceeding action or scope, you can “catch” any has failed, is skipped, or has timed out states from the “try” scope. In effect this makes up your simple try-catch block.

Example

It is possible once you have entered into the catch scope to retrieve details of the resulting try scope by using the expression @result('Scope-Try'). The expression will provide an array of all the actions and their details including if they were successful or failed with a given exception message.

This is really useful but how does it hold up when nested you may ask…

Nested Try-Catch Scopes

Nested try-catch scopes can be handy when you have smaller segments of the larger workflow that can be tried as a group; preventing unnecessary complexity in handling issues and failures later in the workflow or as a whole.

Example

This example still has its overarching try-catch due to the possibility of either sub catches containing actions that can fail, be skipped, or time out.

Nesting try-catch scopes offers the same capabilities as un-nested. However, there are caveats to remember when nesting in this way:

Complexity | readability and maintainability is always paramount when designing workflows.
- Make sure to appropriately and consistently title actions and scopes.
- Add comments, especially on scopes as this can aid in describing the processing and functionality that sits within.
Intentional flow review | given the added complexity through nesting and run after configurations, thorough review and testing of processing flow should be conducted.
- A method of doing this is to test/mock outputs on actions.
Handles the unexpected | as with the single try-catch, this is not a method in handling non-“happy path” results from processing, rather the unexpected failures, skips, or timeouts.

As referred to in the last point in the caveats, if the try-catch both singular and nested aids in the unexpected, how can I add to this pattern to help with handling “un-happy” paths. This cues the Compensating Transaction pattern…

Compensating Transaction Pattern

The Compensating Transaction pattern is useful when you are trying to attain an eventually consistent operation that consists of multiple steps. If one or more of the steps fail, this pattern can be used to undo the steps performed.

One of the most basic forms of compensation or undo is to notify for manual remediation. This is the scenario that I will use as an example.

Scenario

Let’s assume that a taxi booking process needs to be automated as a logic app workflow. There are four steps involved in this process:

Check to see if the customer is an existing customer, and if so obtain an enriched form of their details from our system.
Check if the time slot is available with a local driver.
If the time slot is available, book the time slot with the local driver.
Send a notification to the customer regarding details of the booked time slot and their driver.

If there are any problems with processing these four steps, a notification will need to be sent for manual remediation. This must include:

The steps that were successful
The step that was not able to be performed
The steps that were skipped after the one that failed to be processed

In this scenario and example, the use of the try-catch pattern (nested) is used to catch the unexpected problems in processing. The addition of the Condition action allows us to perform process validation (the action may have succeeded, but did it return the result we desired?). The example further uses the Condition action to validate if the workflow should continue onto the next processing step given the previous may have failed.

Example

The example shows a subset of the steps implemented as the rest are a repeat demonstration.

Given this workflow design, we can process faults in a controlled manner both expected and unexpected. We can control which processing steps should be performed given an error may have occurred, and we can through our transaction log give a full account allowing for full remediation.

There are caveats to remember when implementing this pattern and example:

Complexity | readability and maintainability is always paramount when designing workflows.
- Make sure to appropriately and consistently title actions and scopes.
- Add comments, especially on scopes as this can aid in describing the processing and functionality that sits within.
Intentional flow review | given the added complexity through nesting, conditions, and run after configurations, thorough review and testing of processing flow should be conducted.
- A method of doing this is to test/mock outputs on actions.

Hope this helps and have fun.

Key Vault Reference | Logic and Function Apps using User-Assigned Managed Identity

Mon, 06 Jan 2025 00:00:00 +0000

Overview

Prior to the Christmas break I was involved in writing some integrations that used a mixture of Logic Apps Standard and Function Apps. It was agreed as part of the architecture that user-assigned identities would be the best fit. As part of the implementation, I observed that the differences in configuration setup between system-assigned and user-assigned wasn’t widely understood. This article aims to show a brief run through of both.

Setup and Difference with System-Assigned

System-Assigned

The general process when using a System-Assigned identity is as follows:

Create a Key Vault Instance.
Create secrets required by the application.
Create the app resource (Logic App / Function App)
- As part of the configuration, specify the identity as System Assigned.
- Reference the key vault secret(s) in your App Settings.
Authorise the applications identity read access to key vault or specifically the key vaults secret.

The main points with System-Assigned setup is:

The identity is tied to the created app resource and its life-cycle
The resource cannot reference key vault secrets at the point of creation
- Authorisation to read the key vault secrets has not occurred at this point
The identity cannot be associated with other resources

User-Assigned

The general process when using a User-Assigned identity is as follows:

Create a Key Vault instance
Create secrets required by the application(s)
Create the user-assigned identity
Authorise the user-assigned identity read access to key vault or specifically the key vaults secret.
Create the app resource (Logic App / Function App)

As part of the resource configuration
- Specify the identity as user-assigned and reference the created identity in step 3
- Specify the identity to be used for key vault reference operations by setting the keyVaultReferenceIdentity property to the resource ID of the user-assigned identity
- Reference the key vault secret(s) in your App Settings.

The main points with User-Assigned setup is:

The identity is managed outside the context of a resource and its life-cycle
A resource that uses the identity can read secrets from keyvault at the point of creation
- Given that the authorisation has occurred prior to the resource creation.
The identity can be associated with on or more resources

⚠️ Note One of the most common gotchas [user-assigned] is missing or forgetting to specify the identity to be used for key vault reference operations (keyVaultReferenceIdentity property - Step 5).

Hope this helps and have fun.

Easy Auth | Standard Logic App with Azure API Management

Tue, 26 Nov 2024 00:00:00 +0000

Overview

The recent work that I have been doing with Standard Logic Apps and linking them as backends to Azure API Management has relied on the use of the Logic App Workflow SAS key for security. This is a valid authentication approach, but there are risks that you need to be aware of as well as best practices that you need to be abiding by. Such as:

Some Potential Risks:
- If a SAS is leaked, it can be used by anyone who obtains it to call your Logic App Workflow.
- If a SAS expires and the API Management API has not been updated to make use of the updated SAS, then the integration functionality will be hindered.
Some SAS Best Practices to mitigate risks:
- Always use HTTPS - If a SAS is passed over HTTP and intercepted, an attacker can perform a man-in-the-middle attack and read the SAS.
- Have a revocation plan - Make sure that you are prepared to respond if a SAS is compromised.
- Have a rotation plan - Look to replace the SAS with new ones at regular intervals and include shorter time intervals for the expiration period.

There are other features that can be used to further restrict access to your Logic App, for instance adding IP Address Restrictions to limit traffic to only your API Management Instance.

But what if you require further governance whereby the Logic App requires a valid Entra ID bearer token in order to be invoked. To implement this we are going to make use of Easy Auth.

Easy Auth

Easy Auth is a built-in authentication and authorisation capability provided by Azure App Services and Azure Functions. Easy Auth makes use of federated identity whereby a third-party identity provider manages the user identities and authentication flow for you. Fortunately for us, Standard Logic Apps have the same foundations as Azure Functions and therefore Easy Auth is also extended to Logic Apps Standard.

Easy Auth is a platform feature running on the same virtual machine as your application. Once enabled, any incoming HTTP requests will pass through this feature prior to being handled by your application. Easy Auth runs separately from your application code and can be configured using ARM settings or using a configuration file.

Using Easy Auth and Linking to API Management

As mentioned above, I would like to use Easy Auth to protect my HTTP Triggered Azure Logic App (Standard) workflows, but more importantly, I would like Azure API Management to be the only identity that can be used to make requests to my workflows as shown in the diagram below:

Note:

As we will be invoking the Logic App HTTP triggered workflows with Easy Auth, we no longer need to specify the following parameters in the request:

sp: The permissions; generally ‘read’ or ‘write’

sv: The version number of the query parameters

sig: Shared-Access-Signature

Furthermore, I have opted for Infrastructure as Code (IaC) as my method of implementation, specifically Bicep.

For setup, we will need to conduct the following four steps:

Configure the Logic App to Use Microsoft Entra sign-in.

Working through the Microsoft instructions in the link above, you will require as minimum the following when setting up the Logic App Application Registration:
- Select the supported account type. (I’m using Current tenant - single tenant)
- Setup a Redirect URI for your Logic App:
  
  Select Web for platform and set the URI to /.auth/login/aad/callback. For example, https://contoso.azurewebsites.net/.auth/login/aad/callback.
- Make not of the Application (client) ID.
- Create a Client Secret and store this securely (I’m using Azure DevOps Secure Library Variables as part of a deployment).
  
  This is a secret value that the application uses to prove its identity when requesting a token. This value is saved in your app’s configuration as a slot-sticky application setting named MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. If the client secret isn’t set, sign-in operations from the service use the OAuth 2.0 implicit grant flow, which isn’t recommended.
- Expose an API > Add > Save. This value uniquely identifies the application when it’s used as a resource, allowing tokens to be requested that grant access. It’s used as a prefix for scopes you create.
  
  I am using a single-tenant app and therefore using the default value. Appears as such api://
- Add the user_impersonation scope to your App Registration allowing Admins and users to consent.

Make sure that API Management has been setup with Managed Identity. I am using System Assigned.

@description('Deployment of the APIM instance')
resource apimInstanceDeploy 'Microsoft.ApiManagement/service@2022-08-01' = {
  ...
  identity: {
    type: 'SystemAssigned'
  }
  ...
}

Store the App Registration Secret in KeyVault and Reference in your Logic App Settings to allow the Logic App to prove its identity.

...

@secure()
@description('The client secret for the Easy Auth App Registration')
param applicationEasyAuthClientSecret string

...

@description('Role Definition Id for the Key Vault Secrets User role')
var keyVaultSecretsUserRoleDefId = '4633458b-17de-408a-b874-0445c86b69e6'

...

@description('Deploy the Application Easy Auth App Registration Secret to Keyvault')
resource vaultLogicAppRegSecret 'Microsoft.KeyVault/vaults/secrets@2023-07-01' = {
  name: '${applicationLogicAppName}-EasyAuth-Secret'
  parent: applicationKeyVaultDeploy
  properties: {
    contentType: 'string'
    value: applicationEasyAuthClientSecret
  }
}

...

@description('Deploy the Application Standard Logic App')
resource applicationLogicAppStandardDeploy 'Microsoft.Web/sites@2024-04-01' = {
  name: applicationLogicAppName
  location: location
  identity: {
    type: 'SystemAssigned'
  }
  ...
  resource config 'config@2024-04-01' = {
    name: 'appsettings'
    properties: {
      ...
      MICROSOFT_PROVIDER_AUTHENTICATION_SECRET: '@Microsoft.KeyVault(VaultName=${applicationKeyVaultDeploy.name};SecretName=${vaultLogicAppRegSecret.name})'
      ...
    }
  }
}

...

@description('Create the RBAC for the Logic App to Read the Secret from Key Vault')
resource applicationLogicAppRBACWithKV 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(applicationKeyVaultDeploy.id, applicationLogicAppStandardDeploy.id, keyVaultSecretsUserRoleDefId)
  scope: vaultLogicAppRegSecret
  properties: {
    principalId: applicationLogicAppStandardDeploy.identity.principalId
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', keyVaultSecretsUserRoleDefId)
    principalType: 'ServicePrincipal'
  }
}

Enable Easy Auth on the Standard Logic App using ARM/Bicep Template AuthSettingsV2 or ARM REST API. I am using a Bicep Template.

@description('Setup the Easy Auth config settings for the Standard Logic App')
resource applicationAuthSettings 'Microsoft.Web/sites/config@2023-01-01' = {
  name: 'authsettingsV2'
  parent: applicationLogicAppStandardDeploy // Existing Standard Logic App for Easy Auth to be enabled
  properties: {
    globalValidation: {
      requireAuthentication: true
      unauthenticatedClientAction: 'AllowAnonymous' // Do not change: See note below.
    }
    httpSettings: {
      requireHttps: true
      routes: {
        apiPrefix: '/.auth'
      }
      forwardProxy: {
        convention: 'NoProxy'
      }
    }
    identityProviders: {
      azureActiveDirectory: {
        enabled: true
        registration: {
          openIdIssuer: uri('https://sts.windows.net/', tenant().tenantId)
          clientId: logicAppEasyAuthClientId
          clientSecretSettingName: 'MICROSOFT_PROVIDER_AUTHENTICATION_SECRET'
        }
        validation: {
          allowedAudiences: environment().authentication.audiences // Azure Management Plane [management.core.windows.net and management.azure.com]
          defaultAuthorizationPolicy: {
            allowedPrincipals: {
              identities: [
                apimInstance.identity.principalId // APIM System Assigned Principal Id
              ]
            }
          }
        }
      }
    }
    platform: {
      enabled: true
      runtimeVersion: '~1'
    }
  }
}

Note:

¹EasyAuth is managed by AppService, and for an incoming request, it is a hop that comes before LA Runtime. When EasyAuth is enabled for a Logicapp standard, all incoming requests are validated against the policies in your V2 Auth settings.

If you have “unauthenticatedClientAction”: “Return401” and when the request fails with EasyAuth, those requests are not routed to LA runtime and will fail with 401 from AppService. Therefore, you will also observe broken portal experience with Return401. When you set it to “AllowAnonymous”, all calls (failed and successful) will be routed to the LA runtime. The LA runtime will know if the request failed with EasyAuth or was successful and will process the request accordingly. For example, to get run histories, we authenticate it on SAS specific to that run generated based on the Logic Apps access keys. LA runtime will know that this request failed with EasyAuth but it will be processed successfully as it has valid SAS. The underlying AppService platform will have no knowledge of validating other auth like SAS.

Configure API Management to obtain a valid Bearer token and add it to the request Authorization Header. Implemented through APIM Policy.



    
         />
        
           resource="https://management.azure.com/" output-token-variable-name="msi-access-token" ignore-error="false" />
           name="Authorization" exists-action="override">
 	         @("Bearer " + (string)context.Variables["msi-access-token"])
          
    
    
         />
    
    
         />
    
    
         />

Configure API Management to Append the Logic App Workflow api-version query parameter to the request. Implemented through APIM Policy.



    
         />
         template="__uri__" />
         name="api-version" exists-action="append">
            __api-version__
        
    
    
         />
    
    
         />
    
    
         />

Summary

In short, we have defined our three A’s (Access, Authentication, Authorisation) providing further governance on our Standard Logic App and API Management through the use of Easy Auth. To see my worked example, have a look at my GitHub repository along with a README that explains how to get started.

Hope this helps and have fun.

Trigger workflows in Standard logic apps with Easy Auth | https://techcommunity.microsoft.com/t5/azure-integration-services-blog/trigger-workflows-in-standard-logic-apps-with-easy-auth/ba-p/3207378 ↩︎

Easy Auth | Function App with Azure API Management

Thu, 14 Nov 2024 00:00:00 +0000

Overview

The recent work that I have been doing with Function Apps and linking them as backends to Azure API Management has relied on the use of the Function Apps Function SAS key for security. This is a valid authentication approach, but there are risks that you need to be aware of as well as best practices that you need to be abiding by. Such as:

Some Potential Risks:
- If a SAS is leaked, it can be used by anyone who obtains it to call your Function.
- If a SAS expires and the API Management API has not been updated to make use of the updated SAS, then the integration functionality will be hindered.
Some SAS Best Practices to mitigate risks:
- Always use HTTPS - If a SAS is passed over HTTP and intercepted, an attacker can perform a man-in-the-middle attack and read the SAS.
- Have a revocation plan - Make sure that you are prepared to respond if a SAS is compromised.
- Have a rotation plan - Look to replace the SAS with new ones at regular intervals and include shorter time intervals for the expiration period.

But what if you require further governance whereby the Function App requires a valid Entra ID bearer token in order to be invoked. To implement this we are going to make use of Easy Auth.

Easy Auth

Easy Auth is a built-in authentication and authorisation capability provided by Azure App Services, Azure Functions, and Standard Logic Apps. Easy Auth makes use of federated identity whereby a third-party identity provider manages the user identities and authentication flow for you.

Using Easy Auth and Linking to API Management

As mentioned above, I would like to use Easy Auth to protect my HTTP triggered functions, but more importantly, I would like Azure API Management to be the only identity that can be used to make requests to my functions as shown in the diagram below:

Note:

As we will be invoking the Function App HTTP triggered Functions with Easy Auth, we no longer need to specify the following parameters or details:

Parameter code: Shared-Access-Signature

AuthorizationLevel: When Easy Auth is enabled, the HTTP triggered Functions no longer need to have the AuthorizationLevel set to Function but rather set to Anonymous. This is because Easy Auth will conduct the authorisation prior to reaching your code and no longer requires a SAS key to be provided of which the Function AuthorisationLevel requires.

For setup, we will need to conduct the following steps:

I have opted for Infrastructure as Code (IaC) as my method of implementation, specifically Bicep. I have also opted for Microsoft Entra as my Identity Provider.

Configure the Function App to Use Microsoft Entra sign-in.

Working through the Microsoft instructions in the link above, you will require as minimum the following when setting up the Function App Application Registration:
- Select the supported account type. (I’m using Current tenant - single tenant)
- Setup a Redirect URI for your Function:
  
  Select Web for platform and set the URI to /.auth/login/aad/callback. For example, https://contoso.azurewebsites.net/.auth/login/aad/callback.
- Make not of the Application (client) ID.
- Create a Client Secret and store this securely (I’m using Azure DevOps Secure Library Variables as part of a deployment).
  
  This is a secret value that the application uses to prove its identity when requesting a token. This value is saved in your app’s configuration as a slot-sticky application setting named MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. If the client secret isn’t set, sign-in operations from the service use the OAuth 2.0 implicit grant flow, which isn’t recommended.
- Expose an API > Add > Save. This value uniquely identifies the application when it’s used as a resource, allowing tokens to be requested that grant access. It’s used as a prefix for scopes you create.
  
  I am using a single-tenant app and therefore using the default value. Appears as such api://
- Add the user_impersonation scope to your App Registration allowing Admins and users to consent.

Make sure that API Management has been setup with Managed Identity. I am using System Assigned.

@description('Deployment of the APIM instance')
resource apimInstanceDeploy 'Microsoft.ApiManagement/service@2024-05-01' = {
  ...
  identity: {
    type: 'SystemAssigned'
  }
  ...
}

Store the App Registration Secret in KeyVault and Reference in your Function App Settings to allow the Function App to prove its identity.

...

@secure()
@description('The client secret for the Easy Auth App Registration')
param applicationEasyAuthClientSecret string

...

@description('Role Definition Id for the Key Vault Secrets User role')
var keyVaultSecretsUserRoleDefId = '4633458b-17de-408a-b874-0445c86b69e6'

...

@description('Deploy the Application Easy Auth App Registration Secret to Keyvault')
resource vaultFunctionAppRegSecret 'Microsoft.KeyVault/vaults/secrets@2023-07-01' = {
  name: '${applicationFunctionAppName}-EasyAuth-Secret'
  parent: applicationKeyVaultDeploy
  properties: {
    contentType: 'string'
    value: applicationEasyAuthClientSecret
  }
}

...

@description('Deploy the Application Function App')
resource applicationFunctionAppDeploy 'Microsoft.Web/sites@2024-04-01' = {
  name: applicationFunctionAppName
  location: location
  identity: {
    type: 'SystemAssigned'
  }
  ...
  resource config 'config@2024-04-01' = {
    name: 'appsettings'
    properties: {
      ...
      MICROSOFT_PROVIDER_AUTHENTICATION_SECRET: '@Microsoft.KeyVault(VaultName=${applicationKeyVaultDeploy.name};SecretName=${vaultFunctionAppRegSecret.name})'
      ...
    }
  }
}

...

@description('Create the RBAC for the Function App to Read the Secret from Key Vault')
resource applicationFunctionAppRBACWithKV 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(applicationKeyVaultDeploy.id, applicationFunctionAppDeploy.id, keyVaultSecretsUserRoleDefId)
  scope: vaultFunctionAppRegSecret
  properties: {
    principalId: applicationFunctionAppDeploy.identity.principalId
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', keyVaultSecretsUserRoleDefId)
    principalType: 'ServicePrincipal'
  }
}

Enable Easy Auth on the Function App using ARM/Bicep Template AuthSettingsV2.

@description('Setup the Easy Auth config settings for the Function App')
resource applicationAuthSettings 'Microsoft.Web/sites/config@2024-04-01' = {
  name: 'authsettingsV2'
  parent: applicationFunctionAppDeploy
  properties: {
    globalValidation: {
      requireAuthentication: true
      unauthenticatedClientAction: 'Return401'
    }
    httpSettings: {
      requireHttps: true
      routes: {
        apiPrefix: '/.auth'
      }
      forwardProxy: {
        convention: 'NoProxy'
      }
    }
    identityProviders: {
      azureActiveDirectory: {
        enabled: true
        registration: {
          openIdIssuer: uri('https://sts.windows.net/', tenant().tenantId)
          clientId: functionAppEasyAuthClientId
          clientSecretSettingName: 'MICROSOFT_PROVIDER_AUTHENTICATION_SECRET'
        }
        validation: {
          allowedAudiences: environment().authentication.audiences
          defaultAuthorizationPolicy: {
            allowedPrincipals: {
              identities: [
                apimInstance.identity.principalId
              ]
            }
          }
        }
      }
    }
    platform: {
      enabled: true
      runtimeVersion: '~1'
    }
  }
}

Note:

EasyAuth is managed by the AppService, and for an incoming request, it is a hop that comes before FA Runtime. When EasyAuth is enabled for a Function App, all incoming requests are validated against the policies in your V2 Auth settings.

Configure API Management to obtain a valid Bearer token and add it to the request Authorization Header. Implemented through APIM Policy.



    
         />
        
           resource="https://management.azure.com/" output-token-variable-name="msi-access-token" ignore-error="false" />
           name="Authorization" exists-action="override">
 	         @("Bearer " + (string)context.Variables["msi-access-token"])
          
    
    
         />
    
    
         />
    
    
         />

Summary

In short, we have applied further governance on our Function App and API Management through the use of Easy Auth. To see my worked example, have a look at my GitHub repository along with a README that explains how to get started.

Hope this helps and have fun.

Azure API Management | Function App Backend

Tue, 01 Oct 2024 00:00:00 +0000

Overview

Following on from a previous set of posts from earlier this year where I detailed how to securely implement Logic App Standard backends in Azure API Management, there has been questions on how this would be achieved in a similar manner with Azure Function Apps.

To read-up on how this was achieved with Standard Logic Apps have a look at the following:

At a high level comparison with Azure Logic Apps, Azure Functions are a developer-centric serverless compute offering allowing authors to write code in languages such as C#, Java, Javascript, Python, and PowerShell. Azure Functions are best suited for stateless computation and application specific tasks.

Azure Logic Apps are similar in that they too are a serverless offering but more specifically built as a workflow integration platform. It’s a low code/no code user-friendly development option for designing workflows, integrating different systems, and building business process automation.

Given that Standard Logic Apps share the same compute platform as Azure Function Apps, some of what this post will aim to achieve will be similar to that achieved with the posts highlighted above, but with enough differences that I would suggest reading on.

The method explored here (Linking a Azure Function App as an APIM API Backend) aims to be configurable (Both in Deployment and API setup), and secure; ensuring Principal of Least Privilege (PoLP). The diagram below provides an overview of what is to be achieved:

The overall design aims to abstract the backend from the API Operations, i.e. the backend points to the Azure Function App and the individual operations point to the respective HTTP triggered functions. The design also specifies granular access to the Function specific Shared-Access-Signature (SAS) key as opposed to the Function App SAS key. Providing access to the Function App Host or Admin key is simpler in deployment configuration but has a security concern in allowing access to any Function within the Function App. By utilising the specific Function host SAS key means that only specific access is granted; following in principal of least privilege and lessening the blast radius if a breach of security were to occur. Further to this, the Function SAS key will be held in the applications specific KeyVault where access to this secret will be conducted over Role Based Access Control (RBAC) restricted to the specific secret (again following PoLP). To see further details on this, see Azure RBAC Key Vault | Role Assignment for Specific Secret.

As with my previous posts, I have opted for Infrastructure as Code (IaC) as my method of implementation, specifically Bicep. I have broken down the implementation of the diagram above into two parts, Application Deployment, and API Deployment.

Application Deployment

The following diagram demonstrates how the application backend has been deployed.

The deployment is split into three stages:

Deploy the Core Application Components.
Deploy the Functions to the recently deployed Function App.
Store the Function specific SAS keys in KeyVault for later secure access.

In turn the Bicep for step 1 is shown below:

/**********************************
Bicep Template: Application Deploy
        Author: Andrew Wilson
***********************************/

targetScope = 'resourceGroup'

// ** Parameters **
// ****************

@description('A prefix used to identify the application resources')
param applicationPrefixName string

@description('The name of the application used for tags')
param applicationName string

@description('The location that the resources will be deployed to - defaulting to the resource group location')
param location string = resourceGroup().location

@description('The environment that the resources are being deployed to')
@allowed([
  'dev'
  'test'
  'prod'
])
param env string = 'dev'

// ** Variables **
// ***************

var applicationKeyVaultName = '${applicationPrefixName}${env}kv'
var funcApplicationAppServicePlanName = '${applicationPrefixName}${env}asp'
var funcStorageAccountName = '${applicationPrefixName}${env}st'
var applicationFunctionAppName = '${applicationPrefixName}${env}func'

var isProduction = env == 'prod'

// ** Resources **
// ***************

@description('Deploy the Application Specific Key Vault')
resource applicationKeyVaultDeploy 'Microsoft.KeyVault/vaults@2023-07-01' = {
  name: applicationKeyVaultName
  location: location
  tags: {
    Application: applicationName
    Environment: env
    Version: deployment().properties.template.contentVersion
  }
  properties: {
    sku: {
      family: 'A'
      name: 'standard'
    }
    tenantId: tenant().tenantId
    enableRbacAuthorization: true
    enableSoftDelete: isProduction
  }
}

@description('Deploy the App Service Plan used for Function App')
resource funcAppServicePlanDeploy 'Microsoft.Web/serverfarms@2023-12-01' = {
  name: funcApplicationAppServicePlanName
  location: location
  tags: {
    Application: applicationName
    Environment: env
    Version: deployment().properties.template.contentVersion
  }
  sku: {
    name: 'Y1'
    tier: 'Dynamic'
  }
  properties: {}
}

@description('Deploy the Storage Account used for Function App')
resource funcStorageAccountDeploy 'Microsoft.Storage/storageAccounts@2023-05-01' = {
  name: funcStorageAccountName
  location: location
  tags: {
    Application: applicationName
    Environment: env
    Version: deployment().properties.template.contentVersion
  }
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    supportsHttpsTrafficOnly: true
    minimumTlsVersion: 'TLS1_2'
    defaultToOAuthAuthentication: true
  }
}

@description('Deploy the Application Function App')
resource applicationFunctionAppDeploy 'Microsoft.Web/sites@2023-12-01' = {
  name: applicationFunctionAppName
  location: location
  tags: {
    Application: applicationName
    Environment: env
    Version: deployment().properties.template.contentVersion
  }
  kind: 'functionapp'
  properties: {
    serverFarmId: funcAppServicePlanDeploy.id
    publicNetworkAccess: 'Enabled'
    httpsOnly: true
  }
  resource config 'config@2022-09-01' = {
    name: 'appsettings'
    properties: {
      FUNCTIONS_EXTENSION_VERSION: '~4'
      FUNCTIONS_WORKER_RUNTIME: 'dotnet'
      WEBSITE_NODE_DEFAULT_VERSION: '~18'
      AzureWebJobsStorage: 'DefaultEndpointsProtocol=https;AccountName=${funcStorageAccountDeploy.name};AccountKey=${listKeys(funcStorageAccountDeploy.id, '2019-06-01').keys[0].value};EndpointSuffix=core.windows.net'
      WEBSITE_CONTENTAZUREFILECONNECTIONSTRING: 'DefaultEndpointsProtocol=https;AccountName=${funcStorageAccountDeploy.name};AccountKey=${listKeys(funcStorageAccountDeploy.id, '2019-06-01').keys[0].value};EndpointSuffix=core.windows.net'
      WEBSITE_CONTENTSHARE: funcStorageAccountDeploy.name
    }
  }
}

// ** Outputs **
// *************

output applicationFunctionAppName string  = applicationFunctionAppName

Step 2 is the deployment of the Functions such as this simple C# Hello World request response:


using ...

namespace HelloWorldFunctions
{
    public static class HelloWorld
    {
        [FunctionName("HelloWorld")]
        public static async Task Run(
            [HttpTrigger(AuthorizationLevel.Function, "get", "post", Route = null)] HttpRequest req,
            ILogger log)
        {
            log.LogInformation("C# HTTP trigger function processed a request.");

            string name = req.Query["name"];

            string requestBody = await new StreamReader(req.Body).ReadToEndAsync();
            dynamic data = JsonConvert.DeserializeObject(requestBody);
            name = name ?? data?.name;

            string responseMessage = string.IsNullOrEmpty(name)
                ? "This HTTP triggered function executed successfully. Pass a name in the query string or in the request body for a personalized response."
                : $"Hello, {name}. This HTTP triggered function executed successfully.";

            return new OkObjectResult(responseMessage);
        }
    }
}

Step 3 demonstrated below takes a number of functions, retrieves their SAS keys and creates them as secrets in the Application KeyVault.

Note: To obtain the Function specific SAS key, the Function must have already been deployed to the Function App.

The following Bicep is used to obtain the Function specific SAS key: listKeys(resourceId('Microsoft.Web/sites/functions', applicationFunctionAppName, function),'2023-12-01').default

⚠️ Important

This implementation utilises the default Function SAS key, so special consideration should be taken in your own implementation regarding SAS expiration, revocation, and rotation.

/******************************************
Bicep Template: Application Secrets Deploy
        Author: Andrew Wilson
*******************************************/

targetScope = 'resourceGroup'

// ** Parameters **
// ****************

@description('Name of the Function App to add as a backend')
param applicationFunctionAppName string

@description('The name of the functions in the function app to add secrets for')
param functions string[]

@description('Name of the Key Vault to place secrets into')
param keyVaultName string

// ** Variables **
// ***************

// ** Resources **
// ***************

@description('Retrieve the existing Key Vault instance to store secrets')
resource keyVault 'Microsoft.KeyVault/vaults@2023-07-01' existing = {
  name: keyVaultName
}

@description('Vault the Functions key as a secret - Deployment principle requires RBAC permissions to do this')
resource vaultFunctionsKey 'Microsoft.KeyVault/vaults/secrets@2023-07-01' = [for function in functions: {
  name: '${applicationFunctionAppName}-${function}-key'
  parent: keyVault
  tags: {
    ResourceType: 'FunctionApp'
    ResourceName: '${applicationFunctionAppName}-${function}'
  }
  properties: {
    contentType: 'string'
    value: listKeys(resourceId('Microsoft.Web/sites/functions', applicationFunctionAppName, function),'2023-12-01').default
  }
}]

// ** Outputs **
// *************

API Deployment

The following diagram demonstrates how API Management and the Function App backend API have been deployed.

The deployment is split into two stages:

Deploy an API Management Service Instance.
Deploy respective Backend, Named Values, API, API Operations, and Policies.

The deployment of the API and its operations pointing at the Azure Function App requires the following components:

Azure Role Assignment - This is the authorisation system that we will use to assign APIMs System Assigned Managed Identity access to the applications Key Vault, specifically the SAS Key secrets.
APIM API and API Operations - Represents a set of available operations with each containing a reference to a backend service that implements the API.
APIM Named Values - This is a global collection of name/value pairs within the APIM Instance. Using APIM Policies we can use Named Values to further API configuration. Named Values can store constant string values, secrets, or more importantly Key Vault references to secrets.
APIM Backend - APIM Backend is an HTTP service that implements a front-end API. Setting up the Backend means that we can abstract backend service information, promoting reusability and improved governance.
APIM Policies - Policies are statements that are run sequentially on a given request or response for an API. These statements further our ability to configure the API and its abilities such as adding further parameters, setting a backend, making use of configured Named Values.

The Bicep for Step 1 is shown below:

/**********************************
Bicep Template: APIM Instance Deploy
        Author: Andrew Wilson
***********************************/

targetScope = 'resourceGroup'

// ** Parameters **
// ****************

@description('A prefix used to identify the api resources')
param apiPrefixName string

@description('The location that the resources will be deployed to - defaulting to the resource group location')
param location string = resourceGroup().location

@description('The environment that the resources are being deployed to')
@allowed([
  'dev'
  'test'
  'prod'
])
param env string = 'dev'

@description('The apim publisher email')
param apimPublisherEmail string

@description('The apim publisher name')
param apimPublisherName string

// ** Variables **
// ***************

var apimInstanceName = '${apiPrefixName}${env}apim'

// ** Resources **
// ***************

@description('Deployment of the APIM instance')
resource apimInstanceDeploy 'Microsoft.ApiManagement/service@2022-08-01' = {
  name: apimInstanceName
  location: location
  tags: {
    Environment: env
    Version: deployment().properties.template.contentVersion
  }
  sku: {
    capacity: 0
    name: 'Consumption'
  }
  properties: {
    publisherEmail: apimPublisherEmail
    publisherName: apimPublisherName
  }
  identity: {
    type: 'SystemAssigned'
  }
}

// ** Outputs **
// *************

output apimInstanceName string = apimInstanceName

The Bicep for step 2 makes use of module deployments and policies loaded as text into variables. Further to this, the Function operations are defined within a JSON control file so that the Bicep templates can remain agnostic to operation implementation. The JSON control file also allows the definition of multiple API operations per Function due to a function allowing multiple HTTP Methods such as GET and POST.

The structure of the operations within the Control file allow for APIM to provide a different Operation name to that specified on the backend such as:

APIM /HWGET –> Function /HellowWorld

Each Operation will also detail which Function it is associated with as to utilise the correct Named Value in APIM containing reference to KeyVault Function SaS Key.

The JSON Control file is shown below:

[
    {
        "name": "HelloWorldGet",
        "backendFunctionName": "HelloWorld",
        "rewriteUrl": "/HelloWorld",
        "properties": {
            "displayName": "Hello World GET",
            "method": "GET",
            "urlTemplate": "/HWGET",
            "description": "Hello World GET",
            "templateParameters": [],
            "request": {
                "queryParameters": [
                    {
                        "name": "name",
                        "type": "string",
                        "required": false
                    }
                ],
                "headers": []
            },
            "responses": [
                {
                    "statusCode": 200
                }
            ]
        }
    },
    {
        "name": "HelloWorldPost",
        "backendFunctionName": "HelloWorld",
        "rewriteUrl": "/HelloWorld",
        "properties": {
            "displayName": "Hello World POST",
            "method": "POST",
            "urlTemplate": "/HWPOST",
            "description": "Hello World POST",
            "templateParameters": [],
            "request": {
                "queryParameters": [],
                "headers": []
            },
            "responses": [
                {
                    "statusCode": 200
                }
            ]
        }
    }
]

The Main deployment template is shown below:

/******************************************
Bicep Template: Function App APIM API
        Author: Andrew Wilson
*******************************************/

targetScope = 'resourceGroup'

// ** Parameters **
// ****************

@description('Name of the Function App to add as a backend')
param functionAppName string

@description('Name of the APIM instance')
param apimInstanceName string

@description('Name of the Key Vault instance')
param keyVaultName string

@description('Name of the API to create in APIM')
param apiName string

@description('APIM API path')
param apimAPIPath string

@description('APIM API display name')
param apimAPIDisplayName string

// ** Variables **
// ***************

// Function App Base URL
var funcBaseUrl = 'https://${functionApp.properties.defaultHostName}/api'

// Key Vault Read Access
var keyVaultSecretsUserRoleDefinitionId = '4633458b-17de-408a-b874-0445c86b69e6'

// All Operations Policy
var apimAPIPolicyRaw = loadTextContent('./APIM-Policies/APIMAllOperationsPolicy.xml')
var apimAPIPolicy = replace(apimAPIPolicyRaw, '__apiName__', apiName)

// Operation Policy Template
var apimOperationPolicyRaw = loadTextContent('./APIM-Policies/APIMOperationPolicy.xml')

// Operation List and Details
var apimApiOperations = loadJsonContent('apimApiConfigurations/helloWorldApiOperationsConfiguration.json')

// Obtain single distinct list of functions used in operations 
var allFunction = map(apimApiOperations, op => op.backendFunctionName)
var uniqueFunctions = union(allFunction, allFunction)

// ** Resources **
// ***************

@description('Retrieve the existing APIM Instance, will add APIs and Policies to this resource')
resource apimInstance 'Microsoft.ApiManagement/service@2022-08-01' existing = {
  name: apimInstanceName
}

@description('Create the Function App API in APIM')
resource functionAppAPI 'Microsoft.ApiManagement/service/apis@2022-08-01' = {
  name: apiName
  parent: apimInstance
  properties: {
    displayName: apimAPIDisplayName
    subscriptionRequired: true
    path: apimAPIPath
    protocols: [
      'https'
    ]
  }
}

@description('Retrieve the existing Function App for linking as a backend')
resource functionApp 'Microsoft.Web/sites@2022-09-01' existing = {
  name: functionAppName
}

@description('Deploy function App API operations')
module functionAppAPIOperation 'Modules/apimOperation.azuredeploy.bicep' = [
  for operation in apimApiOperations: {
    name: '${operation.name}-deploy'
    params: {
      parentName: '${apimInstance.name}/${functionAppAPI.name}'
      apiManagementApiOperationDefinition: operation
    }
  }
]

@description('Retrieve the existing application Key Vault instance')
resource keyVault 'Microsoft.KeyVault/vaults@2023-07-01' existing = {
  name: keyVaultName
}

@description('Retrieve the existing function app func key secret')
resource vaultFunctionAppKey 'Microsoft.KeyVault/vaults/secrets@2023-07-01' existing = [
  for function in uniqueFunctions: {
    name: '${functionAppName}-${function}-key'
    parent: keyVault
  }
]

@description('Grant APIM Key Vault Reader for the function app API key secret')
resource grantAPIMPermissionsToSecret 'Microsoft.Authorization/roleAssignments@2022-04-01' = [
  for (function, index) in uniqueFunctions: {
    name: guid(keyVaultSecretsUserRoleDefinitionId, keyVault.id, function)
    scope: vaultFunctionAppKey[index]
    properties: {
      roleDefinitionId: subscriptionResourceId(
        'Microsoft.Authorization/roleDefinitions',
        keyVaultSecretsUserRoleDefinitionId
      )
      principalId: apimInstance.identity.principalId
      principalType: 'ServicePrincipal'
    }
  }
]

@description('Create the named values for the function app API keys')
resource functionAppBackendNamedValues 'Microsoft.ApiManagement/service/namedValues@2022-08-01' = [
  for (function, index) in uniqueFunctions: {
    name: '${apiName}-${function}-key'
    parent: apimInstance
    properties: {
      displayName: '${apiName}-${function}-key'
      tags: [
        'key'
        'functionApp'
        '${apiName}'
        '${function}'
      ]
      secret: true
      keyVault: {
        identityClientId: null
        secretIdentifier: '${keyVault.properties.vaultUri}secrets/${vaultFunctionAppKey[index].name}'
      }
    }
    dependsOn: [
      grantAPIMPermissionsToSecret
    ]
  }
]

@description('Create the backend for the Function App API')
resource functionAppBackend 'Microsoft.ApiManagement/service/backends@2022-08-01' = {
  name: apiName
  parent: apimInstance
  properties: {
    protocol: 'http'
    url: funcBaseUrl
    resourceId: uri(environment().resourceManager, functionApp.id)
    tls: {
      validateCertificateChain: true
      validateCertificateName: true
    }
  }
}

@description('Create a policy for the function App API and all its operations - linking the function app backend')
resource functionAppAPIAllOperationsPolicy 'Microsoft.ApiManagement/service/apis/policies@2022-08-01' = {
  name: 'policy'
  parent: functionAppAPI
  properties: {
    value: apimAPIPolicy
    format: 'xml'
  }
  dependsOn: [
    functionAppBackend
  ]
}

@description('Add query strings via policy')
module operationPolicy './Modules/apimOperationPolicy.azuredeploy.bicep' = [
  for (operation, index) in apimApiOperations: {
    name: 'operationPolicy-${operation.name}'
    params: {
      parentStructureForName: '${apimInstance.name}/${functionAppAPI.name}/${operation.name}'
      functionRelativePath: operation.rewriteUrl
      rawPolicy: apimOperationPolicyRaw
      key: '{{${apiName}-${operation.backendFunctionName}-key}}'
    }
    dependsOn: [
      functionAppAPIOperation
    ]
  }
]

// ** Outputs **
// *************

The APIM All Operations Policy template provides the link to the APIM Function App Backend as shown below:

The Delete Set Header is used to remove subscription key headers from the forwarded request to the backend. For more information see Azure API Management | Unintentional Pass through of Subscription Key Header.



    
         />
         id="functionapp-backend-policy" backend-id="__apiName__" />
         name="Ocp-Apim-Subscription-Key" exists-action="delete" />
    
    
         />
    
    
         />
    
    
         />

The APIM Operation Policy template is used to conduct a uri rewrite to point to the specific Function backend as defined in the JSON Control file. The Policy also appends the Function specific SAS Key “code” Named Value ref to the query parameter set. The actual value is obtained on invocation from KeyVault.



    
         />
         template="__uri__" />
         name="code" exists-action="append">
            __key__
        
    
    
         />
    
    
         />
    
    
         />

The API Operation Module deployment makes use of Bicep User Defined Types to conduct validation of the Operation Control JSON as shown below:

/**********************************
Bicep Template: API Operation Deploy
        Author: Andrew Wilson
***********************************/

targetScope = 'resourceGroup'

// ** User Defined Types **
// ************************

// TYPES: APIM API Operation
// - API Operation Definition
// - Query Parameter
// - Template Parameter
// - Header
// - Response

@export()
@description('APIM API Operation Definition')
@sealed()
type apiOperationDefinition = {
  @minLength(1)
  @maxLength(80)
  @description('The resource name')
  name: string
  @description('The backend function name')
  backendFunctionName: string
  @minLength(1)
  @maxLength(1000)
  @description('Relative URL rewrite template for the Function backend (in policy).')
  rewriteUrl: string
  @description('Properties of the Operation Contract')
  properties: {
    @minLength(1)
    @maxLength(300)
    @description('Operation Name.')
    displayName: string
    @description('A Valid HTTP Operation Method. Typical Http Methods like GET, PUT, POST but not limited by only them.')
    method: string
    @minLength(1)
    @maxLength(1000)
    @description('Relative URL template identifying the target resource for this operation. May include parameters. Example: /customers/{cid}/orders/{oid}/?date={date}')
    urlTemplate: string
    @maxLength(1000)
    @description('Description of the operation. May include HTML formatting tags.')
    description: string
    @description('Collection of URL template parameters.')
    templateParameters: templateParameter[]?
    @description('An entity containing request details.')
    request: {
      @description('Collection of operation request query parameters.')
      queryParameters: queryParameter[]?
      @description('Collection of operation request headers.')
      headers: header[]?
    }
    @description('Array of Operation responses.')
    responses: response[]?
  }
}

@export()
type queryParameter = {
  @description('Parameter name.')
  name: string
  @description('Parameter type.')
  type: string
  @description('Specifies whether parameter is required or not.')
  required: bool?
}

@export()
type templateParameter = {
  @description('Parameter name.')
  name: string
  @description('Parameter type.')
  type: string
  @description('Specifies whether parameter is required or not.')
  required: bool?
}

@export()
type header = {
  @description('Header name.')
  name: string
  @description('Header type.')
  type: string
  @description('Specifies whether header is required or not.')
  required: bool?
  @description('Header values.')
  values: string[]?
}

@export()
type response = {
  @description('Operation response HTTP status code.')
  statusCode: int
}

// ** Parameters **
// ****************

@description('API Management Service API Name Path')
param parentName string

@description('Definition of the operation to create')
param apiManagementApiOperationDefinition apiOperationDefinition

// ** Variables **
// ***************

// ** Resources **
// ***************

@description('Deploy function App API operation')
resource functionAppAPIGetOperation 'Microsoft.ApiManagement/service/apis/operations@2022-08-01' = {
  name: '${parentName}/${apiManagementApiOperationDefinition.name}'
  properties: apiManagementApiOperationDefinition.properties
}

// ** Outputs **
// *************

The API Operation Policy Module Deployment is as follows:

/********************************************
Bicep Template: APIM FUNC API Operation Policy
        Author: Andrew Wilson
********************************************/

targetScope = 'resourceGroup'

// ** Parameters **
// ****************

@description('The Parent naming structure for the Policy')
param parentStructureForName string

@description('The function relative path')
param functionRelativePath string

@description('The raw policy document template')
param rawPolicy string

@description('The named value name for the workflow key')
param key string = ''

// ** Variables **
// ***************

var policyURI = replace(rawPolicy, '__uri__', functionRelativePath)
var policyKEY = replace(policyURI, '__key__', key)

// ** Resources **
// ***************

@description('Add query strings via policy')
resource operationPolicy 'Microsoft.ApiManagement/service/apis/operations/policies@2022-08-01' = {
  name: '${parentStructureForName}/policy'
  properties: {
    value: policyKEY
    format: 'xml'
  }
}

// ** Outputs **
// *************

Hope this helps, and have fun.

Speaking | Azure Security Do's and Don'ts: A Developer's Checklist for Secure Azure Applications

Thu, 15 Aug 2024 00:00:00 +0000

I recently had the privilege to be hosted on the Azure on Air podcast by the Turbo360 team. I had a great conversation with Lex discussing the importance of a “security first” mindset in the world of Azure solutions, and how this mindset should be carried out as a priority in every stage from Requirements Gathering, Design, Development, and Release.

During our time together we discussed topics such as:

The Three A’s: Access, Authentication, and Authorisation:

By keeping these concepts in mind throughout, developers can ensure their solutions are secure and driven with defined access routes.
Blast Radius: Minimise the Impact of Security Breaches:

Following the good practice of Principal of Least Privilege(PoLP), developers should consider the security impact of granting services and identities permissions and access that are beyond their required need.
Managed Identities: Removing Manual Management:

Azure has made considerable efforts in Managed Identities and Role Based Access Control(RBAC), thus removing the need to use keys that need to be rolled over or may be visible and vulnerable to attackers.
Observability: Tracking Integrations End-to-End:

Observability is critical in ensuring that Azure solutions are working as intended and within acceptable bounds. This is more achievable than ever with tools such as Application Insights and Log Analytics.

Have a watch and enjoy.

Azure Role Based Access Control (RBAC) | Removing Orphaned Role Assignments

Thu, 04 Jul 2024 00:00:00 +0000

Problem Space

Deploying solutions into Azure that rely on Role Based Access often involve us creating IaC automation for the assignment of roles, such as:

A services access to Key Vault
A services access to a Key Vault specific secret
A services access to a storage account
A services access to a Service Bus Queue or Topic

In many of these instances we may wish to leverage the source resource identity (System Assigned Managed Identity) for the assigned access.

But what happens when we delete the source resource, are the role assignments applied on the target resources removed?

The answer… No they are not.

Your target resources are left with orphaned role assignments. In many cases the use of User Assigned Managed Identity is used to avoid this particular issue as the identity exists regardless of the resource life cycle, at which point there is no orphaning.

But whats the big problem, just redeploy and everything should line up again right?

Unfortunately this is not the case. If you follow through with this sentiment, you will receive the following error from the Azure Resource Manager:

Tenant ID, application ID, principal ID, and scope are not allowed to be updated. (code: RoleAssignmentUpdateNotPermitted)

The reasoning behind is role assignments require a globally unique identifier (GUID) of which out of good practices you have made deterministic for solution deployments. So when you have deleted and recreated the resource the underlying principal ID has now changed, but the role assignment name has not. This infers the problem, you cannot create two role assignments with the same name, even in different Subscriptions, followed with properties of an existing role assignment cannot be changed.

Surly there is a automated process in Azure that will remove these for me? Sadly this is not the case and it has pushed many in resulting to manually searching for and removing these orphaned assignments. This is tedious and time consuming, not to mention requiring the user to have User Access Administrator role access which you may not wish to grant to everyone.

Solution

The solution I came up with uses PowerShell and the az cli to retrieve all role assignments for a given subscription. This is then filtered down to any orphaned assignments scoped to resources in a specific resource group (scope can be changed to what you need). Given that there are orphaned assignments these are then removed through the az cli.

The script looks like this:

$ResourceGroupName = ""

$roleAssignments = az role assignment list --all | ConvertFrom-Json
$orphaned = $roleAssignments | Where-Object { ($_.principalName -eq "") -and ($_.scope -match "resourcegroups/$ResourceGroupName") }
$orphaned.Count
$orphaned | ForEach-Object { az role assignment delete --ids $_.id }

To run this script you will need the following Roles:

Directory.Read.All
User Access Administrator (At the respective Scope)

To avoid assigning User Access Administrator to anyone who may need to run this script, I placed this script into a CI/CD pipeline of which the Pipeline Identity has the roles applied as shown above. This way, the development team can remove orphaned role assignments with ease without the need for elevation of privilege.

⚠️ Best Practice of Least Privilege.

Hope this helps, and have fun

Azure API Management | Enable Tracing for an API

Sun, 02 Jun 2024 00:00:00 +0000

Background

For a while now I have made good use of the Trace functionality in the API Management (APIM) Test Client. If you haven’t, I would highly advise having a look. The Trace functionality allows us to unveil (debug) the complexity and inner workings of our reverse proxy APIs (their routing / hierarchical policies / alternate backends / caching / etc.). With the Portal this is fairly trivial to do, you simply:

Navigate to your API Management instance.
Select one of your APIs that you would like to Trace.
Select the Test tab.
Select one of the Operations to send a request to.
Select Trace.

By enabling tracing on the API you are now able to inspect each part of the request:

Inbound | The original request received from the caller and the policies applied.
Backend | The requests API Management sent to the backend and the response it received.
Outbound | The policies applied to the response before sending back to the caller.
On error | The errors that occurred during processing of the request and any policies applied to those errors.

⚠️ Important

Be careful when enabling tracing as it can expose sensitive information in the trace data.

Problem Space

Although the APIM Test client has certainly proven useful, I have wondered if there are any other methods of enabling and obtaining the trace for a given API. More importantly, brining the development experience back to something that we are use to such as Visual Studio Code, Postman, etc.

Just over a week ago, I had a conversation with the APIM product group, of which they mentioned that the service has a REST API that can be used to enable trace functionality. After a bit of digging, I found the documentation around this and thought I would share my findings and implementation with you.

⚠️ Important

Before we get started, please bare in mind:

The API Management REST API version 2023-05-01-preview or later is required.

The Identity used to call the REST API must be assigned the Contributor or higher role on the API Management instance.

Enabling tracing on an API through the REST API is a four step process:

We need to obtain trace credentials using the List Debug Credentials API.
Enable Tracing on your API by adding the Trace Credential token as a header (Apim-Debug-Authorization) to your request.
Given that the Trace Credential token was valid, we need to retrieve the Trace ID from the response header Apim-Trace-Id.
Invalid Cases Include:
- Token expired | The response will include a Apim-Debug-Authorization-Expired header with information about expiration date.
- Token obtained for wrong API | The response will include a Apim-Debug-Authorization-WrongAPI header with an error message.
We need to retrieve the trace log by calling the List Trace API using the Trace ID from the previous step.

In both steps 1 and 4, you will need to provide a valid Authorization Bearer token where the identity is assigned Contributor or higher on the APIM instance.

Given that this is not the simplicity that we know and love in the Test Client, making and orchestrating these various Rest calls can and most certainly will take time when conducted singularly. What we need is tooling or extensions to such tooling that will enable us to orchestrate these various calls so that we can obtain the trace logs with repeatable ease.

My Solution

I required a solution that would allow me to orchestrate the various calls with repeatable ease whilst also keeping me close to the tooling that I know and love. My solution is the REST Client extension in VS Code. Using this extension I can:

Orchestrate the various Rest calls required.
Use variables to make as much of the calls required somewhat generic.
The extension provides me the ability to obtain an AAD (Entra ID) token.

By default if a token has already been obtained, the extension will reuse the previous token for the specified directory from an in-memory cache. Expired tokens are refreshed automatically. (The token cache can be manually cleared, or is by default cleared upon closure of VS Code).

The implementation that I have come to is as follows:

# ***************************************************************************************************************
# Enable tracing for an APIM API
# ------------------------------
#
# ⚠️Note:
#    The following steps require API Management REST API version 2023-05-01-preview or later. 
#    You must be assigned the Contributor or higher role on the API Management instance to call the REST API.
#
#  Steps:
#  1. Obtain trace credentials by calling the List debug credentials API.
#  2. Call the API with the trace credentials.
#  3. Retrieve trace logs.
#
#  Author: Andrew Wilson
# ***************************************************************************************************************

# -----------------
# Custom Variables 
# -----------------

@subscriptionId = REPLACEME
@resourceGroup = REPLACEME
@apimServiceName = REPLACEME
@apiName = REPLACEME

# -----------------
#    Rest Steps
# -----------------

### 1.Obtain trace credentials by calling the List debug credentials API.

# @name TraceCreds
POST https://management.azure.com/subscriptions/{{subscriptionId}}/resourceGroups/{{resourceGroup}}/providers/Microsoft.ApiManagement/service/{{apimServiceName}}/gateways/managed/listDebugCredentials
?api-version=2023-05-01-preview
Content-Type: application/json
Authorization: {{$aadToken}}

{
    "credentialsExpireAfter": "PT1H",
    "apiId": "/subscriptions/{{subscriptionId}}/resourceGroups/{{resourceGroup}}/providers/Microsoft.ApiManagement/service/{{apimServiceName}}/apis/{{apiName}}",
    "purposes": ["tracing"]
}

### 2.Call the API with the trace credentials.

# @name ApiOperationTracing
Author your API request here but make sure to keep the following Header in place.
Apim-Debug-Authorization: {{TraceCreds.response.body.$.token}}

### 3.Retrieve Trace Logs

# @name ObtainedTraceLogs
POST https://management.azure.com/subscriptions/{{subscriptionId}}/resourceGroups/{{resourceGroup}}/providers/Microsoft.ApiManagement/service/{{apimServiceName}}/gateways/managed/listTrace
?api-version=2023-05-01-preview
Content-Type: application/json
Authorization: {{$aadToken}}

{
    "traceId": "{{ApiOperationTracing.response.headers.Apim-Trace-Id}}"
}

Have a play and see if this extends your tracing capabilities.

Azure API Management | Unintentional Removal of Request Forwarding to Backend

Fri, 03 May 2024 00:00:00 +0000

Problem Space

I have recently been working on an API scoped policy within API Management, the policy ideally should not be impacted by any policies defined higher up in the hierarchy.

For reference, this means that any policies defined at the Product, Workspace, or Global level will not be inherited at the API scope for the given API Definition. See diagram below:

Ideally this means that my API traffic will start at my non-hierarchical policy definition, conduct any policy processing prior to being sent off to the backend, and then sent back to the calling outbound system.

Example Policy definition with the removal of which indicates inheritance:

In practice this is not what happened.

The API that I had defined should have successfully returned with a Status Code of 200 and a Json Payload. However, what I actually received was a successful API run with a return of Status Code 200 but no Json Payload.

Further investigation into this highlighted that the API request was never making it out to the Backend.

This being the case, a reviewal of the higher scoped policies showed that there was indeed a policy that is core to the APIM reverse proxy behaviour, and I had excluded this due to my lack of inheritance.

Offending Policy that was excluded due to my lack of inheritance
  
  	 />
  

For reference, the forward-request policy forwards the incoming request to the backend service specified in the request context. And more importantly the policy is included in the Global Backend Policy by default.

Conclusion

Two things came from this,

I fixed my problem by applying the forward-request policy in my API policy definition.
More importantly, Always review hierarchical policies when removing inheritance as there may be behaviour that you will require, even if you didn’t place it there.

Azure API Management | Governing Product Visibility and Access via Groups

Tue, 30 Apr 2024 00:00:00 +0000

Overview

In API Management, users and groups are a core aspect of the Developer Portal and are used to manage the visibility and access to respective products and their APIs.

One of the common questions that I often get asked is, “how do I appropriately govern the groups effectively so that I can ensure that the correct groups and users have access to the appropriate resources and those who don’t… well don’t?”.

Background

API Management has three immutable built in system groups used to govern access:

Administrators | These are not consumers or customers of your APIs but are rather the users who build and manage the API Management service instances, creating the APIs, operations, and products that are used by developers. You can’t add users to this group.

The group contains the admin email account provided at the time of service creation. Azure subscription administrators are members of this group.
Developers | These are customers and consumers that build applications using your APIs. Developers are granted access to and are authenticated into the developer portal. Membership to this group is managed by the system and cannot be added to by you.

Developers (Authenticated Users) invited, created, pulled from external groups, or otherwise signed up are all created as a developer and gain automatic membership to this group.
Guests | These are users such as prospective customers and are able to visit the developer portal without having to be authenticated. APIs that guests can view are managed by yourself as well as the type of access such as read-only access (the ability to view APIs but not call them). As with the previous two groups, membership is managed by the system.

Then there is the ability to create custom groups and or use external groups in associated Microsoft Entra tenants. These custom groups can be used to further govern developer visibility and access to API products.

Note:

User accounts from MS Entra ID or B2C groups are still created as new developer user entities within APIM and associated with the Developers System group as well as the desired Entra ID group.

Governing Access

The key to understanding Group Access is to remember that all developers (no matter how they have been created) are associated with the Developers System group. In effect this means that any product that has been associated with the Developers system group will be accessible to all users (except Guests given association).

Therefore do not blindly associate the Developer System group to your products unless you expect all users past, present, and future to have access to them.

Rather in answer create custom groups/associate Entra ID groups of which can be used to provide access to specific products. Further to this, granularity is key for security, following the good practice of least privilege (A user or entity should only have access to the specific data, resources and applications needed to complete a required task.).

Have a play, and hope this helps.

Microsoft.Web/Connections | Access Policies

Wed, 10 Apr 2024 00:00:00 +0000

Problem Space

I have recently been adding email alerting to some Logic App Standard workflows as part of the error handling flow. In doing so I made use of an existing Office 365 Outlook Connector in the Azure Subscription; the connector is not built in for Standard Logic Apps but is rather part of the Managed Api Connections.

Managed Api Connectors require more than just the connection details to be detailed in the Logic Apps connections.json configuration as shown below:

{
  "managedApiConnections": {
    "office365": {
      "api": {
        "id": "@appsetting('office365_apiId')"
      },
      "authentication": {
        "type": "ManagedServiceIdentity"
      },
      "connection": {
        "id": "@appsetting('office365_connectionId')"
      },
      "connectionRuntimeUrl": "@appsetting('office365_connectionRuntimeUrl')"
    }
  }
}

The Managed API Connector also requires that the Logic App has been granted access to the Connector through the use of Access Policies. This can be configured through the Azure Portal or through infrastructure deployments, in my case I have opted for infrastructure deployments with the use of Bicep templates.

It was at this point that I realised that the Access Policy resource which is a child resource to Microsoft.Web/connections has not been documented, obtainable through an Azure Portal template export, or through the Resource Explorer.

Solution

From digging around the Access Policy resource has the following ARM Template Schema:

{
   "type": "Microsoft.Web/connections/accessPolicies",
   "apiVersion": "2016-06-01",
   "name": "[concat(''),'/','')]",
   "location": "",
   "dependsOn": [
      "[resourceId('Microsoft.Web/connections', parameters('connection_name'))]"
   ],
   "properties": {
      "principal": {
         "type": "ActiveDirectory",
         "identity": {
            "objectId": "",
            "tenantId": ""
         }
      }
   }
}

Resource Properties

Parameter Description

The name for your managed API connection, for example office365

The object ID for your Microsoft Entra identity, for example the system assigned managed identity of the logic app

The tenant ID for your Microsoft Entra identity

Parameter	Description
	The name for your managed API connection, for example office365
	The object ID for your Microsoft Entra identity, for example the system assigned managed identity of the logic app
	The tenant ID for your Microsoft Entra identity

In Bicep this takes on the following form:

@description('Create the access policy for the Logic App to access the managed Api Connection ')
resource managedAPIConnectionAccessPolicy 'Microsoft.Web/connections/accessPolicies@2016-06-01' = {
  name: logicApp.name // Using the Logic App Name for readability
  parent: managedAPIConnector
  location: Location
  properties: {
    principal: {
      type: 'ActiveDirectory'
      identity: {
        tenantId: subscription().tenantId
        objectId: logicApp.identity.principalId // Using the System Assigned Managed Identity of the Logic App
      }
    }
  }
}

Note

The Bicep tooling will give you the following warning but will not hinder in both the transpilation into ARM or in the deployment of the resource:

Resource type "Microsoft.Web/connections/accessPolicies@2016-06-01" does not have types available.

Azure API Management | Logic App (Standard) Backend Using a Swagger Definition

Thu, 01 Feb 2024 00:00:00 +0000

Overview

After setting up a Logic App (Standard) Backend in Azure API Management (APIM) in my last post, I wanted to try and see if I could create a Swagger definition from a Standard Logic App which could then be used to simplify the API authoring process in APIM. This post shows my methods of doing so.

If you haven’t already I would recommend reading my previous post as this one will be working off of the building blocks of the last.

As with my previous post, the high-level architecture has not changed and neither has the overall aim as shown below.

The design aims to abstract the backend from the api operations, i.e. the backend points to the Logic App and the individual operations point to the respective workflows. The design also specifies granular access to the workflow Shared-Access-Signature (sig) held in the applications specific KeyVault (to see further details on this, see Azure RBAC Key Vault | Role Assignment for Specific Secret). Furthermore, the additional required parameters that are necessary to call a workflow have been implemented through APIM policies to remove the need for callers to understand backend implementation.

I have opted for Infrastructure as Code (IaC) as my method of implementation, specifically Bicep. I have broken down the implementation of the diagram above into two parts, Application Deployment, and API Deployment.

Problem Space

Having come across the ARM REST API to generate a Swagger definition for a consumption Logic App, I went searching for the same functionality for Standard Logic Apps. Given a short time searching, I found the REST APIs situated under App Services with the Swagger generation API no where to be seen.

But would this stop me… No.

Knowing that I can retrieve a detailed definition of a Standard Logic App through the Azure Resource Manager, I started looking at methods of stripping out the detail that I would need to construct a Swagger Definition.

My chosen method to do this is through a PowerShell script using both ARM REST APIs and the az cli. This choice will allow me to run the script as non-interactive in future DevOps CI/CD pipelines.

Application Deployment

Our first step toward generating the Swagger definition for our Logic App is to deploy an instance of our Logic App to Azure. The process has not changed from the last post apart from the addition of step 4. As shown in the diagram below, step 4 is where we will use the PowerShell script that I have written to extract the core details of our Logic App and workflows to construct a Swagger Definition.

The script has been designed to take a ControlFile.json that you update with one or more HTTP triggered workflows and API details to assist in the retrieval and generation of the definition. There is an example control file in my GitHub repository.

The SpecCreator.ps1 takes the following parameters:

<#
    .SYNOPSIS
	Creates a Swagger definition for a select Standard Logic App and its specified Workflows.

    .DESCRIPTION
	Uses a series of parameters to derive the Standard Logic App and the Workflows to include in the base Swagger definition template. 

    .PARAMETER SubscriptionId
    The ID of the Subscription that the Standard Logic App is Hosted in.

    .PARAMETER ResourceGroupName
    The Resource Group Name that the Standard Logic App is Hosted in.

    .PARAMETER LogicAppName
    The Name of the Standard Logic App to use for the Swagger Definition.

    .PARAMETER APITitle
    API Name used to define the set of operations.

    .PARAMETER APIDescription
    Description of the API and its set of operations.

    .PARAMETER APIVersion
    None-Mandatory - Specified version of the API. Default is 1.0.0.0

    .PARAMETER SpecTemplatePath
    None-Mandatory - Base path to the swagger definition template, doesn't include the name of the file.

    .PARAMETER ControlFile
    None-Mandatory - Base path to the json control file used to identify the set of Workflows to extract as operations for the swagger definition, doesn't include the name of the file.

	.PARAMETER InteractiveMode
	If specified will request the user to interactively login into Azure for az tooling.
    #>

The script then uses a series of ARM REST API calls to obtain the following detail:

Request Schema (if one is provided).
Workflow Definition.

Using the Workflow Definition, we can interrogate the Workflow Trigger for details such as:

HTTP Method.
Relative Paths.
- Note: Path Parameters are expected to be wrapped with curly braces, for example:
  - /users/{id}
  - /cars/{carId}/drivers/{driverId}
  - cars/{carId}/drivers/{driverId}
  - /{carId}/{driverId}
  - {carId}

Once all the Workflow details have been obtained, the script uses an imported tokenised Swagger Definition to generate the respective Definition for your Standard Logic App and Workflows.

API Deployment

For the most part, the API Deployment has not changed. We are using the same Bicep to create the APIM Instance, APIM Backends/Named Values, and Policies. The main change to our Bicep Deployment occurs in step 2.1 as shown in the diagram below.

Rather than constructing the API and API Operations individually through Bicep Resources as done in the previous post, we are going to define the APIM API along with the generated Swagger Definition from earlier steps. APIM validates the Swagger Definition and uses it to construct the API and Operations on our behalf.

The three main differences to our API deployment are:

We need to make use of the loadTextContent Bicep function to load the generated Swagger Definition into our Bicep Template.
```
var swaggerDefinition = loadTextContent('../../SwaggerGenerator/GeneratedSpec.json')
```

We need to change the Microsoft.ApiManagement/service/apis resource to accept our generated Swagger Definition:

@description('Create the Logic App API in APIM - Loading in Swagger Definition')
resource logicAppAPI 'Microsoft.ApiManagement/service/apis@2022-08-01' = {
  name: apiName
  parent: apimInstance
  properties: {
    displayName: apimAPIDisplayName
    subscriptionRequired: true
    path: apimAPIPath
    protocols: [
      'https'
    ]
    format: 'swagger-json'
    value: swaggerDefinition
  }
}

We need to remove the following Bicep Module call to create the API Operations as this will now be done for us.

@description('Deploy logic App API operation')
module logicAppAPIOperation 'Modules/apimOperation.azuredeploy.bicep' = [for operation in apimAPIOperations :{
  name: '${operation.name}-deploy'
  params: {
    parentName: '${apimInstance.name}/${logicAppAPI.name}'
    lgCallBackObject: listCallbackUrl(resourceId('Microsoft.Web/sites/hostruntime/webhooks/api/workflows/triggers', logicAppName, 'runtime', 'workflow', 'management', operation.lgWorkflowName, operation.lgWorkflowTrigger), '2022-09-01')
    operationDisplayName: operation.displayName
    operationMethod: operation.method
    operationName: operation.name

  }
}]

Summary

The main benefit of using this method over constructing the API and Operations through Bicep is that we only need to define the backing API once.

If you would like to spin up a demo of this implementation or would like to use it as the basis of something you are working on, the source to all my work is in my GitHub repository along with a README that explains how to get started.

Have a go and see if this simplifies your Standard Logic App APIM Configurations.

Azure API Management | Logic App (Standard) Backend

Tue, 02 Jan 2024 00:00:00 +0000

Overview

Updated [31/01/2024]: See New Post showing methods of linking a Logic App Standard as a Backend to APIM through a Swagger Definition.

I have recently been reviewing the method in which a Logic App (Standard) workflow would be setup as an API in API Management. My aim is to overcome and simplify the limitation whereby directly importing a Logic App (Standard) workflow is not available, only in consumption.

After some exploration I believe I have identified a configurable and secure method in setting up the front-to-backend routing as can be seen in the diagram below:

The overall design aims to abstract the backend from the api operations, i.e. the backend points to the Logic App and the individual operations point to the respective workflows. The design also specifies granular access to the workflow Shared-Access-Signature (sig) held in the applications specific KeyVault (to see further details on this, see Azure RBAC Key Vault | Role Assignment for Specific Secret). Furthermore, the additional required parameters that are necessary to call a workflow have been implemented through APIM policies to remove the need for callers to understand backend implementation.

Application Deployment

The following diagram demonstrates how the application backend has been deployed.

The deployment is split into three stages:

Deploy the Core Application Components.
Deploy the Logic Workflows to the recently deployed Logic App.
Store the Workflow SAS keys in KeyVault for later secure use.

In turn the Bicep for step 1 is shown below:

/***************************************
Bicep Template: Application Core Deploy
***************************************/

targetScope = 'resourceGroup'

// ** Parameters **
// ****************

@description('A prefix used to identify the application resources')
param applicationPrefixName string

@description('The name of the application used for tags')
param applicationName string

@description('The location that the resources will be deployed to - defaulting to the resource group location')
param location string = resourceGroup().location

@description('The environment that the resources are being deployed to')
@allowed([
  'dev'
  'test'
  'prod'
])
param env string = 'dev'

// ** Variables **
// ***************

var applicationKeyVaultName = '${applicationPrefixName}${env}kv'
var lgApplicationAppServicePlanName = '${applicationPrefixName}${env}asp'
var lgStorageAccountName = '${applicationPrefixName}${env}st'
var applicationLogicAppName = '${applicationPrefixName}${env}logic'

var isProduction = env == 'prod'

// ** Resources **
// ***************

@description('Deploy the Application Specific Key Vault')
resource applicationKeyVaultDeploy 'Microsoft.KeyVault/vaults@2023-07-01' = {
  name: applicationKeyVaultName
  location: location
  tags: {
    Application: applicationName
    Environment: env
    Version: deployment().properties.template.contentVersion
  }
  properties: {
    sku: {
      family: 'A'
      name: 'standard'
    }
    tenantId: tenant().tenantId
    enableRbacAuthorization: true
    enableSoftDelete: isProduction
  }
}

@description('Deploy the App Service Plan used for Logic App Standard')
resource lgAppServicePlanDeploy 'Microsoft.Web/serverfarms@2022-09-01' = {
  name: lgApplicationAppServicePlanName
  location: location
  tags: {
    Application: applicationName
    Environment: env
    Version: deployment().properties.template.contentVersion
  }
  kind: 'elastic'
  sku: {
    name: 'WS1'
    tier: 'WorkflowStandard'
    size: 'WS1'
    family: 'WS'
    capacity: 1
  }
}

@description('Deploy the Storage Account used for Logic App Standard')
resource lgStorageAccountDeploy 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: lgStorageAccountName
  location: location
  tags: {
    Application: applicationName
    Environment: env
    Version: deployment().properties.template.contentVersion
  }
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    supportsHttpsTrafficOnly: true
    minimumTlsVersion: 'TLS1_2'
    defaultToOAuthAuthentication: true
  }
}

@description('Deploy the Application Standard Logic App')
resource applicationLogicAppStandardDeploy 'Microsoft.Web/sites@2022-09-01' = {
  name: applicationLogicAppName
  location: location
  tags: {
    Application: applicationName
    Environment: env
    Version: deployment().properties.template.contentVersion
  }
  kind: 'functionapp,workflowapp'
  properties: {
    serverFarmId: lgAppServicePlanDeploy.id
    publicNetworkAccess: 'Enabled'
    httpsOnly: true
  }
  resource config 'config@2022-09-01' = {
    name: 'appsettings'
    properties: {
      FUNCTIONS_EXTENSION_VERSION: '~4'
      FUNCTIONS_WORKER_RUNTIME: 'node'
      WEBSITE_NODE_DEFAULT_VERSION: '~18'
      AzureWebJobsStorage: 'DefaultEndpointsProtocol=https;AccountName=${lgStorageAccountDeploy.name};AccountKey=${listKeys(lgStorageAccountDeploy.id, '2019-06-01').keys[0].value};EndpointSuffix=core.windows.net'
      WEBSITE_CONTENTAZUREFILECONNECTIONSTRING: 'DefaultEndpointsProtocol=https;AccountName=${lgStorageAccountDeploy.name};AccountKey=${listKeys(lgStorageAccountDeploy.id, '2019-06-01').keys[0].value};EndpointSuffix=core.windows.net'
      WEBSITE_CONTENTSHARE: lgStorageAccountDeploy.name
      AzureFunctionsJobHost__extensionBundle__id: 'Microsoft.Azure.Functions.ExtensionBundle.Workflows'
      AzureFunctionsJobHost__extensionBundle__version: '${'[1.*,'}${' 2.0.0)'}'
      APP_KIND: 'workflowApp'
    }
  }
}

// ** Outputs **
// *************

output keyVaultName string = applicationKeyVaultName
output applicationLogicAppName string  = applicationLogicAppName

Step 2 is the deployment of the workflow definition such as this very simple request response:

{
    "definition": {
        "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
        "actions": {
            "Response": {
                "type": "Response",
                "kind": "Http",
                "inputs": {
                    "statusCode": 200
                },
                "runAfter": {}
            }
        },
        "contentVersion": "1.0.0.0",
        "outputs": {},
        "triggers": {
            "When_a_HTTP_request_is_received": {
                "type": "Request",
                "kind": "Http"
            }
        }
    },
    "kind": "Stateless"
}

Step 3 demonstrated below takes a number of workflows, retrieves their SAS keys and creates them as secrets in the Application KeyVault.

/*****************************************
Bicep Template: Application Secrets Deploy
*****************************************/

targetScope = 'resourceGroup'

// ** Parameters **
// ****************

@description('Name of the Logic App to place workflow(s) sig into KeyVault')
param applicationLogicAppName string

@description('Name of the Key Vault to place secrets into')
param keyVaultName string

@description('Array of Workflows to obtain sigs from.')
param workflows array = [
  {
    workflowName: ''
    workflowTrigger: ''
  }
]

// ** Variables **
// ***************



// ** Resources **
// ***************

@description('Retrieve the existing Logic App')
resource logicApp 'Microsoft.Web/sites@2022-09-01' existing = {
  name: applicationLogicAppName
}

@description('Retrieve the existing Key Vault instance to store secrets')
resource keyVault 'Microsoft.KeyVault/vaults@2023-07-01' existing = {
  name: keyVaultName
}

@description('Vault the Logic App workflow sig as a secret - Deployment principle requires RBAC permissions to do this')
resource vaultLogicAppKey 'Microsoft.KeyVault/vaults/secrets@2023-07-01' = [for workflow in workflows: {
  name: '${logicApp.name}-${workflow.workflowName}-sig'
  parent: keyVault
  tags: {
    ResourceType: 'LogicAppStandard'
    ResourceName: logicApp.name
  }
  properties: {
    contentType: 'string'
    value: listCallbackUrl(resourceId('Microsoft.Web/sites/hostruntime/webhooks/api/workflows/triggers', logicApp.name, 'runtime', 'workflow', 'management', workflow.workflowName, workflow.workflowTrigger), '2022-09-01').queries.sig
  }
}]

// ** Outputs **
// *************

API Deployment

The following diagram demonstrates how API Management and the Logic App backend API have been deployed.

The deployment is split into two stages:

Deploy an API Management Service Instance.
Deploy respective Backend, API, API Operations, and Policies.

Our deployment of the API and its operations pointing at the Standard Logic App requires the following components:

Azure Role Assignment - This is the authorisation system that we will use to assign APIMs System Assigned Managed Identity access to the applications Key Vault, specifically the sig secret.
APIM API and API Operations - Represents a set of available operations with each containing a reference to a backend service that implements the API.
APIM Named Values - This is a global collection of name/value pairs within the APIM Instance. Using APIM Policies we can use Named Values to further API configuration. Named Values can store constant string values, secrets, or more importantly Key Vault references to secrets.
APIM Backend - APIM Backend is an HTTP service that implements a front-end API. Normally with consumption Logic Apps when imported into APIM a Backend Service is automatically created for you. This is not currently possible with Standard Logic Apps. However, Standard Logic Apps have the same foundations as Azure Functions which means that we can set this up through custom backends (i.e. is treated as a Function Backend).
- Setting up the Backend means that we can abstract backend service information, promoting reusability and improved governance.
APIM Policies - Policies are statements that are run sequentially on a given request or response for an API. These statements further our ability to configure the API and its abilities such as adding further parameters, setting a backend, making use of configured Named Values.

The Bicep for step 1 is shown below:

/**********************************
Bicep Template: APIM Instance Deploy
***********************************/

targetScope = 'resourceGroup'

// ** Parameters **
// ****************

@description('A prefix used to identify the api resources')
param apiPrefixName string

@description('The location that the resources will be deployed to - defaulting to the resource group location')
param location string = resourceGroup().location

@description('The environment that the resources are being deployed to')
@allowed([
  'dev'
  'test'
  'prod'
])
param env string = 'dev'

@description('The apim publisher email')
param apimPublisherEmail string

@description('The apim publisher name')
param apimPublisherName string

// ** Variables **
// ***************

var apimInstanceName = '${apiPrefixName}${env}apim'

// ** Resources **
// ***************

@description('Deployment of the APIM instance')
resource apimInstanceDeploy 'Microsoft.ApiManagement/service@2022-08-01' = {
  name: apimInstanceName
  location: location
  tags: {
    Environment: env
    Version: deployment().properties.template.contentVersion
  }
  sku: {
    capacity: 0
    name: 'Consumption'
  }
  properties: {
    publisherEmail: apimPublisherEmail
    publisherName: apimPublisherName
  }
  identity: {
    type: 'SystemAssigned'
  }
}

// ** Outputs **
// *************

output apimInstanceName string = apimInstanceName

The Bicep for step 2 makes use of module deployments and policies loaded as text into variables. The Main deployment template is shown below:

/******************************************
Bicep Template: Logic App Standard APIM API
*******************************************/

targetScope = 'resourceGroup'

// ** Parameters **
// ****************

@description('Name of the Logic App to add as a backend')
param logicAppName string

@description('Name of the APIM instance')
param apimInstanceName string

@description('Name of the Key Vault instance')
param keyVaultName string

@description('Name of the API to create in APIM')
param apiName string

@description('APIM API path')
param apimAPIPath string

@description('APIM API display name')
param apimAPIDisplayName string

@description('Array of API operations')
param apimAPIOperations array = [
  {
    name: ''
    displayName: ''
    method: ''
    lgWorkflowName: ''
    lgWorkflowTrigger: ''
  }
]

// ** Variables **
// ***************

// Logic App Base URL
var lgBaseUrl = 'https://${logicApp.properties.defaultHostName}/api'

// Key Vault Read Access
var keyVaultSecretsUserRoleDefinitionId = '4633458b-17de-408a-b874-0445c86b69e6'

// All Operations Policy
var apimAPIPolicyRaw = loadTextContent('./APIM-Policies/APIMAllOperationsPolicy.xml')
var apimAPIPolicy = replace(apimAPIPolicyRaw, '__apiName__', apiName)

// Operation Policy Template
var apimOperationPolicyRaw = loadTextContent('./APIM-Policies/APIMOperationPolicy.xml')

// ** Resources **
// ***************

@description('Retrieve the existing APIM Instance, will add APIs and Policies to this resource')
resource apimInstance 'Microsoft.ApiManagement/service@2022-08-01' existing = {
  name: apimInstanceName
}

@description('Create the Logic App API in APIM')
resource logicAppAPI 'Microsoft.ApiManagement/service/apis@2022-08-01' = {
  name: apiName
  parent: apimInstance
  properties: {
    displayName: apimAPIDisplayName
    subscriptionRequired: true
    path: apimAPIPath
    protocols: [
      'https'
    ]
  }
}

@description('Retrieve the existing Logic App for linking as a backend')
resource logicApp 'Microsoft.Web/sites@2022-09-01' existing = {
  name: logicAppName
}

@description('Deploy logic App API operation')
module logicAppAPIOperation 'Modules/apimOperation.azuredeploy.bicep' = [for operation in apimAPIOperations :{
  name: '${operation.name}-deploy'
  params: {
    parentName: '${apimInstance.name}/${logicAppAPI.name}'
    lgCallBackObject: listCallbackUrl(resourceId('Microsoft.Web/sites/hostruntime/webhooks/api/workflows/triggers', logicAppName, 'runtime', 'workflow', 'management', operation.lgWorkflowName, operation.lgWorkflowTrigger), '2022-09-01')
    operationDisplayName: operation.displayName
    operationMethod: operation.method
    operationName: operation.name

  }
}]

@description('Retrieve the existing application Key Vault instance')
resource keyVault 'Microsoft.KeyVault/vaults@2023-07-01' existing = {
  name: keyVaultName
}

@description('Retrieve the existing logicapp workflow sig secret')
resource vaultLogicAppKey 'Microsoft.KeyVault/vaults/secrets@2023-07-01' existing = [for operation in apimAPIOperations: {
  name: '${logicAppName}-${operation.lgWorkflowName}-sig'
  parent: keyVault
}]

@description('Grant APIM Key Vault Reader for the logic app API key secret')
resource grantAPIMPermissionsToSecret 'Microsoft.Authorization/roleAssignments@2022-04-01' = [for (operation, index) in apimAPIOperations: {
  name: guid(keyVaultSecretsUserRoleDefinitionId, keyVault.id, operation.lgWorkflowName)
  scope: vaultLogicAppKey[index]
  properties: {
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', keyVaultSecretsUserRoleDefinitionId)
    principalId: apimInstance.identity.principalId
    principalType: 'ServicePrincipal'
  }
}]

@description('Create the named values for the logic app API sigs')
resource logicAppBackendNamedValues 'Microsoft.ApiManagement/service/namedValues@2022-08-01' = [for (operation, index) in apimAPIOperations: {
  name: '${apiName}-${operation.name}-sig'
  parent: apimInstance
  properties: {
    displayName: '${apiName}-${operation.name}-sig'
    tags: [
      'sig'
      'logicApp'
      '${apiName}'
      '${operation.name}'
    ]
    secret: true
    keyVault: {
      identityClientId: null
      secretIdentifier: '${keyVault.properties.vaultUri}secrets/${vaultLogicAppKey[index].name}'
    }
  }
  dependsOn: [
    grantAPIMPermissionsToSecret
  ]
}]

@description('Create the backend for the Logic App API')
resource logicAppBackend 'Microsoft.ApiManagement/service/backends@2022-08-01' = {
  name: apiName
  parent: apimInstance
  properties: {
    protocol: 'http'
    url: lgBaseUrl
    resourceId: uri(environment().resourceManager, logicApp.id)
    tls: {
      validateCertificateChain: true
      validateCertificateName: true
    }
  }
}

@description('Create a policy for the logic App API and all its operations - linking the logic app backend')
resource logicAppAPIAllOperationsPolicy 'Microsoft.ApiManagement/service/apis/policies@2022-08-01' = {
  name: 'policy'
  parent: logicAppAPI
  properties: {
    value: apimAPIPolicy
    format: 'xml'
  }
  dependsOn: [
    logicAppBackend
  ]
}

@description('Add query strings via policy')
module operationPolicy './Modules/apimOperationPolicy.azuredeploy.bicep' = [for (operation, index) in apimAPIOperations: {
  name: 'operationPolicy-${operation.name}'
  params: {
    parentStructureForName: '${apimInstance.name}/${logicAppAPI.name}/${operation.name}'
    rawPolicy: apimOperationPolicyRaw
    apiVersion: listCallbackUrl(resourceId('Microsoft.Web/sites/hostruntime/webhooks/api/workflows/triggers', logicAppName, 'runtime', 'workflow', 'management', operation.lgWorkflowName, operation.lgWorkflowTrigger), '2022-09-01').queries['api-version']
    sp: listCallbackUrl(resourceId('Microsoft.Web/sites/hostruntime/webhooks/api/workflows/triggers', logicAppName, 'runtime', 'workflow', 'management', operation.lgWorkflowName, operation.lgWorkflowTrigger), '2022-09-01').queries.sp
    sv: listCallbackUrl(resourceId('Microsoft.Web/sites/hostruntime/webhooks/api/workflows/triggers', logicAppName, 'runtime', 'workflow', 'management', operation.lgWorkflowName, operation.lgWorkflowTrigger), '2022-09-01').queries.sv
    sig: '{{${apiName}-${operation.name}-sig}}'
  }
  dependsOn: [
    logicAppAPIOperation
  ]
}]

// ** Outputs **
// *************

The APIM All Operations Policy template is as follows:

The Deletion Set Header is used to remove subscription key headers from the forwarded request to the backend. For more information see Azure API Management | Unintentional Pass through of Subscription Key Header.




    
         />
         id="logicapp-backend-policy" backend-id="__apiName__" />
         name="Ocp-Apim-Subscription-Key" exists-action="delete" />
    
    
         />
    
    
         />
    
    
         />

The APIM Operation Policy template is as follows:

By setting the parameters as policy means that those calling the API do not need to be aware of backend configuration. Thus allowing for complete separation of concerns.



    
         />
         name="api-version" exists-action="append">
            __api-version__
        
         name="sp" exists-action="append">
            __sp__
        
         name="sv" exists-action="append">
            __sv__
        
         name="sig" exists-action="append">
            __sig__
        
    
    
         />
    
    
         />
    
    
         />

The API Operation Module deployment is as follows:

/**********************************
Bicep Template: API Operation Deploy
***********************************/

targetScope = 'resourceGroup'

// ** Parameters **
// ****************

@description('API Management Service API Name Path')
param parentName string

@description('Name of the API Operation')
param operationName string

@description('Display name for the API operation')
param operationDisplayName string

@description('API Operation Method e.g. GET')
param operationMethod string

@description('Logic App Call Back object containing URL and other details')
param lgCallBackObject object

// ** Variables **
// ***************

var operationUrlBase = split(split(lgCallBackObject.value, '?')[0], '/api')[1]
var hasRelativePath = lgCallBackObject.?relativePath != null ? true : false
var pathParametersList = hasRelativePath ? lgCallBackObject.relativePathParameters : []
var pathParameters = [for pathParameter in pathParametersList: {
    name: pathParameter
    type: 'string'
}]
var RelativePathHasBeginingSlash = hasRelativePath ? first(lgCallBackObject.relativePath) == '/' : false
var operationUrl = hasRelativePath && RelativePathHasBeginingSlash ? '${operationUrlBase}${lgCallBackObject.relativePath}' : hasRelativePath && !RelativePathHasBeginingSlash ? '${operationUrlBase}/${lgCallBackObject.relativePath}' : operationUrlBase

// ** Resources **
// ***************

@description('Deploy logic App API operation')
resource logicAppAPIGetOperation 'Microsoft.ApiManagement/service/apis/operations@2022-08-01' = {
  name: '${parentName}/${operationName}'
  properties: {
    displayName: operationDisplayName
    method: operationMethod
    urlTemplate: operationUrl
    templateParameters: hasRelativePath ? pathParameters : null
  }
}

// ** Outputs **
// *************

The API Operation Policy Module Deployment is as follows:

/********************************************
Bicep Template: APIM LG API Operation Policy
********************************************/

targetScope = 'resourceGroup'

// ** Parameters **
// ****************

@description('The Parent naming structure for the Policy')
param parentStructureForName string

@description('The raw policy document template')
param rawPolicy string

@description('The Logic App service API version')
param apiVersion string

@description('The Logic App workflow permissions')
param sp string

@description('The Logic App workflow version number of the query parameters')
param sv string

@description('The named value name for the workflow sig')
param sig string

// ** Variables **
// ***************

var policyApiVersion = replace(rawPolicy, '__api-version__', apiVersion)
var policySP = replace(policyApiVersion, '__sp__', sp)
var policySV = replace(policySP, '__sv__', sv)
var policySIG = replace(policySV, '__sig__', sig)


// ** Resources **
// ***************

@description('Add query strings via policy')
resource operationPolicy 'Microsoft.ApiManagement/service/apis/operations/policies@2022-08-01' = {
  name: '${parentStructureForName}/policy'
  properties: {
    value: policySIG
    format: 'xml'
  }
}

// ** Outputs **
// *************

Have a go and see if this simplifies your Standard Logic App APIM Configurations.

Azure Integration Services on Andrew Wilson's Blog

Azure Logic Apps Standard | Send Custom Events to Application Insights

Introduction

The Use Case

Understanding the Application Insights Ingestion Endpoint

Implementation

Step 1: Configure Application Insights Connection in Bicep

Step 2: Create Logic App Parameters

Step 3: Add the Workflow Actions and Event Payload

Step 4: Send the Event via HTTP

Step 5: Query Your Events

Summary

Azure Function Apps | OkObjectResult Returns Empty JSON After Moving to .NET 9 Isolated Worker Runtime

The Problem

Why This Happens

1. In-Process to Isolated Worker Migration

2. JSON Serializer Change

The Solutions

Option 1: Use Native Isolated Worker Types (Recommended)

Option 2: Add MVC Services with Newtonsoft.Json (Quick Fix)

Which Should You Choose?

Takeaway

Agent Loop | Azure Logic Apps Just Got Smarter

Microsoft Announcement

What Is Agent Loop?

Why This Matters

1. From Orchestrators to Orchestrators-With-Brains

2. For BizTalk Migrations, This Changes the Equation

3. Bridging Structured and Unstructured Worlds

What Could This Enable?

The Bigger Picture

A Word of Caution

Getting Started

Final Thoughts

Further Reading:

Logic App | Access Key Revocation and Regeneration

Overview

Solution

Logic App | Try-Catch Pattern, Nested Scopes, And Compensating Transaction Pattern

The Try-Catch Pattern

Nested Try-Catch Scopes

Compensating Transaction Pattern

Key Vault Reference | Logic and Function Apps using User-Assigned Managed Identity

Overview

Setup and Difference with System-Assigned

Easy Auth | Standard Logic App with Azure API Management

Overview

Easy Auth

Using Easy Auth and Linking to API Management

Summary

Easy Auth | Function App with Azure API Management

Overview

Easy Auth

Using Easy Auth and Linking to API Management

Summary

Azure API Management | Function App Backend

Overview

Application Deployment

API Deployment

Speaking | Azure Security Do's and Don'ts: A Developer's Checklist for Secure Azure Applications

Azure Role Based Access Control (RBAC) | Removing Orphaned Role Assignments

Problem Space

Solution

Azure API Management | Enable Tracing for an API

Background

Problem Space

My Solution

Azure API Management | Unintentional Removal of Request Forwarding to Backend

Problem Space

Conclusion

Azure API Management | Governing Product Visibility and Access via Groups

Overview

Background

Governing Access

Microsoft.Web/Connections | Access Policies

Problem Space

Solution

Azure API Management | Logic App (Standard) Backend Using a Swagger Definition

Overview

Problem Space