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=<key>;IngestionEndpoint=https://<region>.in.applicationinsights.azure.com/;LiveEndpoint=https://<region>.livediagnostics.monitor.azure.com/;ApplicationId=<ID>

// Broken Down
//------------
InstrumentationKey=<key>

IngestionEndpoint=https://<region>.in.applicationinsights.azure.com/

LiveEndpoint=https://<region>.livediagnostics.monitor.azure.com/

ApplicationId=<ID>

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://<region>.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!

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<HttpResponseData> 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.

Modernising legacy applications is always a journey, and recently I tackled moving an existing WCF web service into Azure App Service. If you’ve worked with WCF, you’ll know the web.config file is the nerve centre, handling everything from parameters to connection strings.

But here’s the catch, this service needs to run in multiple environments (Development, Test, and Production) each with its own unique settings. That means multiple config files:

• Web.Dev.Config
• Web.Test.Config
• Web.Production.Config

The challenge

I didn’t want to build and maintain three separate web packages, one for each environment. That’s a recipe for drift and deployment headaches. Instead, I wanted a single build artifact that could be promoted through environments, swapping out only the environment-specific config as needed.

Enter web.config transformations. With these, you can:

• Keep a base web.config
• Layer on environment-specific transforms (Web.Dev.Config, etc.)

But when should the transformation happen? There are two main options, each with its own pros and cons:

1. At build time (using MSBuild):

   • The transformation is applied as part of the build process, so the output artifact already contains the environment-specific configuration.
   • This approach is simple if you only ever deploy to one environment per build, but it means you need to build a separate artifact for each environment. This breaks the principle of binary promotion, where the same artifact is promoted through Dev, Test, and Production. It also increases the risk of inconsistencies between builds.

2. At deployment (using the AzureRMWebAppDeployment@4 Azure DevOps Task):

   • The transformation is applied as part of the deployment process, allowing you to use a single, environment-agnostic build artifact and inject the correct configuration at deploy time.
   • This is the preferred approach for most modern pipelines, as it enables true binary promotion, reduces build times, and ensures that what you test is exactly what you deploy to production. It also aligns with best practices for repeatable, reliable deployments.

Solution: deploy-time transforms

Here’s how I set it up:

Build pipeline

# YAML
...

stages:
- stage: 'Build_Packages'
  jobs:
    - job: 'Build_WCFService'
      steps:

        - checkout: self
          fetchDepth: 0

        - task: VSBuild@1
          displayName: 'Build the WCF Service Solution'
          inputs:
            solution: '$(Build.SourcesDirectory)\*.sln'
            msbuildArgs: '/p:OutputPath=$(Build.ArtifactStagingDirectory)\WCFService /p:IsTransformWebConfigDisabled=true'
            platform: 'any cpu'
            vsVersion: 'latest'
            configuration: 'Release'
            clean: true

        - task: ArchiveFiles@2
          displayName: 'Archive WCF Service Build Output'
          inputs:
            rootFolderOrFile: '$(Build.ArtifactStagingDirectory)\WCFService\_PublishedWebsites\WCFService.Web'
            includeRootFolder: false
            archiveType: 'zip'
            archiveFile: '$(Build.ArtifactStagingDirectory)\WCFService\WCFService.zip'
            replaceExistingArchive: true

        - task: PublishPipelineArtifact@1
          displayName: 'Publish WCF Service Build Artifact'
          inputs:
            targetPath: '$(Build.ArtifactStagingDirectory)\WCFService\WCFService.zip'
            publishLocation: 'pipeline'
            artifactName: 'WCFService'

Release pipeline

Each environment (Dev, Test, Production) will get its own stage. The key is to ensure the correct environment name is set so the right transform is applied.

# YAML
...
- stage: 'Dev'
  displayName: 'Deploy to Dev Environment'
  variables:
  - group: 'Dev'
  dependsOn: 'Build_Packages'
  condition: succeeded()
  jobs:
    - deployment: Deploy_to_Dev
      environment: WCFServiceDev
      strategy:
        runOnce:
          deploy:
            steps:
              - template: EnvironmentDeploy.azurepipelinetemplate.yml
                parameters:
                  ARMConn: 'Dev'

- stage: 'Test'
  displayName: 'Deploy to Test Environment'
  variables:
  - group: 'Test'
  dependsOn: 'Dev'
  condition: succeeded()
  jobs:
    - deployment: Deploy_to_Test
      environment: WCFServiceTest
      strategy:
        runOnce:
          deploy:
            steps:
              - template: EnvironmentDeploy.azurepipelinetemplate.yml
                parameters:
                  ARMConn: 'Test'

- stage: 'Production'
  displayName: 'Deploy to Production Environment'
  variables:
  - group: 'Prod'
  dependsOn: 'Test'
  condition: succeeded()
  jobs:
    - deployment: Deploy_to_Production
      environment: WCFServiceProd
      strategy:
        runOnce:
          deploy:
            steps:
              - template: EnvironmentDeploy.azurepipelinetemplate.yml
                parameters:
                  ARMConn: 'Production'

Deployment template

#YAML

steps:

  - download: current
    displayName: 'Download the wcf Service Web package'
    artifact: WCFService

  ...

  - task: AzureRMWebAppDeployment@4
    displayName: 'Deploy WCF Service Web App'
    inputs:
      ConnectionType: 'AzureRM'
      azureSubscription: ${{ parameters.ARMConn }}
      appType: 'webApp'
      WebAppName: '$(armOutput.AppServiceName)'
      Package: '$(Pipeline.Workspace)/WCFService/WCFService.zip'
      enableXmlTransform: true

Here’s the bit that tripped me up: in multi-stage pipelines, the Release.EnvironmentName variable isn’t set by default. Without it, Azure DevOps doesn’t know which transform to apply. The fix? Explicitly set the variable in each stage:

# YAML
- stage: 'Dev'
  displayName: 'Deploy to Dev Environment'
  variables:
  ...
  - name: 'Release.EnvironmentName'
    value: 'Dev'
  ...

- stage: 'Test'
  displayName: 'Deploy to Test Environment'
  variables:
  ...
  - name: 'Release.EnvironmentName'
    value: 'Test'
  ...

- stage: 'Production'
  displayName: 'Deploy to Production Environment'
  variables:
  ...
  - name: 'Release.EnvironmentName'
    value: 'Production'
  ...

Troubleshooting and tips

Common pitfalls:

• Ensure your transform files (e.g., Web.Dev.config) are included in your build artifacts. If they’re missing, check your .csproj or project file to confirm they’re marked as Content and set to Copy to Output Directory if needed.
• File names are case-sensitive on some systems, double-check spelling and casing.
• If transforms aren’t being applied, verify that the Release.EnvironmentName variable is set correctly and matches your transform file naming.

Security note: Avoid storing secrets or sensitive values directly in your config files. Use Azure Key Vault or pipeline secrets for sensitive data, and reference them via environment variables or pipeline variables where possible.

Wrapping up

With this approach, you get a single, reusable build artifact and environment-specific configuration at deployment, no more juggling multiple packages. It’s a small change that makes your pipeline cleaner and your deployments more reliable.

Hope this helps, happy deploying!

Deploying updates to production environments demands both speed and control. Azure App Service deployment slots, combined with Azure DevOps pipelines, offer a powerful way to manage releases, enabling teams to validate changes in a live-like environment before they go public. However, ensuring that only reviewed and approved changes reach your users is critical for maintaining reliability and compliance.

Azure App Service Slots unlock powerful advantages:

• Site Review. Preview and test your site before it goes live, ensuring everything works as expected.
• Warmed-up Instances. Swap with confidence. Your instances are pre-warmed, so there’s no downtime, seamless traffic redirection, and zero dropped requests.
• Instant Rollback. If something goes wrong after a swap, simply swap back to restore your last known good version in seconds.

Best of all, deployment slots come at no extra cost. Check the Azure App Service limits to see how many slots your App Service Tier supports.

Automatic vs. Manual Slot Swaps

When it comes to swapping slots, there are two main approaches: automatic and manual.

• Automatic swaps are ideal when you want to quickly promote changes without a review, while still benefiting from pre-warmed instances and instant rollback.
• Manual swaps give you the opportunity to review and verify your site before it goes live, adding an extra layer of confidence.

But how do you keep a manual swap process governed and controlled? That’s where Azure DevOps pipelines and approvals come in.

In this article, you’ll learn how to set up a robust, approval-driven slot swap process in Azure DevOps.

Defining Azure Resources with Bicep

First, we need to define the resources needed in Azure. To do this I am going to use Infrastructure as Code (IaC). The template shown below creates the following resources:

• App Service Plan.
• App Service linked to the App Service Plan
  • Sub Resource that defines the App Service App Settings
• App Service Deployment Slot. Only created for Production environments - this is enforced through a conditional on the resource

Bicep Template: App Service and Deployment Slot

// Bicep

/**********************************
Bicep Template: App Service Deploy
Author: Andrew Wilson
***********************************/

targetScope = 'resourceGroup'

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

@description('Org Project Name')
param projectName string

@description('Application Name sitting within the project')
param applicationName string

@description('location name')
param location string = resourceGroup().location

@description('Environment name')
param env string = 'dev'

@description('App Service Plan sku name')
param appServicePlanSkuName string

@description('App Service Plan sku tier')
param appServicePlanSkuTier string

@description('Name of the deployment slot')
param deploymentSlotName string = 'staging'

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

var appServicePlanName string = 'asp-${applicationName}-${env}-${location}'
var appServiceName string = 'app-${applicationName}-${env}-${location}'

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

@description('Deploy an Azure App Service Plan')
resource AppServicePlan 'Microsoft.Web/serverfarms@2024-11-01' = {
  name: appServicePlanName
  location: location
  tags: {
    project: projectName
    application: applicationName
    environment: env
    version: deployment().properties.template.contentVersion
  }
  sku: {
    name: appServicePlanSkuName
    tier: appServicePlanSkuTier
  }
}

@description('Deploy an Azure App Service')
resource AppService 'Microsoft.Web/sites@2024-11-01' = {
  name: appServiceName
  location: location
  tags: {
    project: projectName
    application: applicationName
    environment: env
    version: deployment().properties.template.contentVersion
  }
  properties: {
    serverFarmId: AppServicePlan.id
    httpsOnly: true
  }
  resource AppServiceAppSettings 'config@2024-11-01' = {
    name: 'appsettings'
    properties: {
      ...
    }
  }  
}

@description('Deploy a deployment slot for the App Service')
resource deploymentSlot 'Microsoft.Web/sites/slots@2024-11-01' = if (env == 'prod') {
  name: deploymentSlotName
  parent: AppService
  location: location
  tags: {
    project: projectName
    application: applicationName
    environment: env
    version: deployment().properties.template.contentVersion
  }
  properties: { }
}

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

@description('Outputs the App Service Name')
output appServiceName string = appServiceName

Important Note: Avoiding AutoSwap for Manual Swaps

Make sure that the DeploymentSlot resource does not have AutoSwap setup as this will counteract when Manual Swap is used. Such that the following process would be observed:

1. Deploy to Staging slot.
2. AutoSwap kicks in and swaps Staging with Production.
3. After Manual Approval, Slots are swapped again
4. You are now in the originating position with the new site still in Staging and Production with the old.

Designing the Azure DevOps Pipeline

Next we will setup our Azure DevOps Yaml pipeline. The pipeline’s goal is to orchestrate artifact building and environment deployments while adhering to DevOps best practices, such as binary promotion.

Pipeline Stages Explained

The pipeline has the following stages:

1. Build_Packages. Build a single set of artifacts that have been tested and versioned. (Best practice of Binary Promotion)

   The stage has two jobs to handle both Azure Bicep Templates and the App Service Web Package.

2. Development. Deploy to the Development Environment using an environment agnostic pipeline template*.

3. Staging. Deploy to the Staging Environment using an environment agnostic pipeline template*.

4. Production. Deploy to the Production Environment using an environment agnostic pipeline template*.

*The environment agnostic pipeline template is a reusable template for all environments.

Pipeline YAML: Build and Environment Deployments

# Yaml
# Orchestrating Template: Build And Environment Deployments

...

stages:
- stage: 'Build_Packages'
  jobs:
    - job: 'Test_Build_And_Version_Bicep_Templates'
      steps:

        ...

        - task: PublishPipelineArtifact@1
          displayName: 'Publish ARMOutput as template build artifact'
          inputs:
            targetPath: '$(Build.ArtifactStagingDirectory)/templates'
            publishLocation: 'pipeline'
            artifactName: 'ARMtemplates'

    - job: 'Build_and_Version_AppService'
      steps:

		...

        - task: PublishPipelineArtifact@1
          displayName: 'Publish App Service Build Artifact'
          inputs:
            targetPath: '$(Build.ArtifactStagingDirectory)/AppService.zip'
            publishLocation: 'pipeline'
            artifactName: 'AppService'


- stage: 'Development'
  displayName: 'Deploy to Dev Environment'
  ...
  jobs:
    - deployment: Deploy_to_Dev
      ...
            steps:
              - template: EnvironmentDeploy.azurepipelinetemplate.yml
                ...

- stage: 'Staging'
  displayName: 'Deploy to Staging Environment'
  ...
  jobs:
    - deployment: Deploy_to_Staging
      ...
            steps:
              - template: EnvironmentDeploy.azurepipelinetemplate.yml
                ...

- stage: 'Production'
  displayName: 'Deploy to Production Environment'
  ...
  jobs:
    - deployment: Deploy_to_Production
      ...
            steps:
              - template: EnvironmentDeploy.azurepipelinetemplate.yml
                ...

Once the Build_Packages stage has completed successfully, we now have two pipeline artifacts, ARMtemplates and AppService. In each environment deploy these two artifacts will be downloaded and used alongside environment specific Library Variable Groups to create specific environment deployments.

Environment-Agnostic Deployment Template

The environment agnostic template is shown below and has the following steps:

1. Artifact Downloads. Downloads the two pipeline artifacts, ARMtemplates and AppService.
2. Azure Resource Group Deployment. Using the built ARM template, specific environment library variable group and ARM Connection.
3. Custom PowerShell Script to Obtain Azure Deployment Outputs. Deployment output such as appServiceName will be created as job variables ready for future tasks to access.
4. Azure Web App Deploy (Specific for Dev and Staging). This task deploys straight to the production slot for non production environments.
5. Azure Web App Deploy (Specific for Prod). This task deploys to the staging slot ready for a manual slot swap.

Pipeline YAML Template: Reusable Environment-Agnostic Deployments

# Yaml
# Environment Deploy Template: Deploy Azure Resources and Obtain Outputs, Deploy App Service

steps:

  - download: current
    displayName: 'Download ARM templates'
    artifact: ARMtemplates

  - download: current
    displayName: 'Download the App Service Web package'
    artifact: AppService

  - task: AzureResourceManagerTemplateDeployment@3
    displayName: 'Deploy App Service ARM template'
    inputs:
      deploymentScope: 'Resource Group'
      azureResourceManagerConnection: ${{ parameters.ARMConn}}
      subscriptionId: '$(subscriptionId)'
      action: 'Create Or Update Resource Group'
      resourceGroupName: '$(resourceGroupName)'
      location: '$(location)'
      templateLocation: 'Linked artifact'
      csmFile: '$(Pipeline.Workspace)/ARMtemplates/AppService.azuredeploy.json'
      deploymentMode: 'Incremental'
      deploymentOutputs: deploymentOutputs
      overrideParameters: >-
        ...        

  - task: PowerShell@2
    name: armOutput
    displayName: 'Obtain Azure Deployment outputs'
    inputs:
      targetType: 'inline'
      script: |
        if (![string]::IsNullOrEmpty( '$(deploymentOutputs)' )) {
          $DeploymentOutputs = convertfrom-json '$(deploymentOutputs)'

          $DeploymentOutputs.PSObject.Properties | ForEach-Object {
              $keyname = $_.Name
              $value = $_.Value.value
              Write-Host "The value of [$keyName] is [$value]"
              Write-Host "##vso[task.setvariable variable=$keyname;isOutput=true]$value"
          }
        }        

  - task: AzureWebApp@1
    displayName: 'Deploy App Service - Dev and Staging Environment Only'
    condition: ne(variables['env'], 'prod')
    inputs:
      azureSubscription: ${{ parameters.ARMConn }}
      appType: 'webApp'
      appName: '$(armOutput.appServiceName)'
      package: '$(Pipeline.Workspace)/AppService/AppService.zip'

  - task: AzureWebApp@1
    displayName: 'Deploy App Service to Staging Slot - Prod Environment Only'
    condition: eq(variables['env'], 'prod')
    inputs:
      azureSubscription: ${{ parameters.ARMConn }}
      appType: 'webApp'
      appName: '$(armOutput.appServiceName)'
      deployToSlotOrASE: true
      resourceGroupName: '$(resourceGroupName)'
      slotName: '$(slotName)'
      package: '$(Pipeline.Workspace)/AppService/AppService.zip'

Accessing ARM Output Variables Across Jobs

Given that I will also need to access the appServiceName ARM Output that has been outputted from the armOutput task as a variable in future jobs, I have used the Output Variable for use in future jobs configuration.

Rather than job only:

##vso[task.setvariable variable=$keyname]$value

It uses the IsOutput so we can setup dependencies and access later:

##vso[task.setvariable variable=$keyname;isOutput=true]$value

Note: Accessing a Output Variable is different to a non-output variable:

Non-output Variable: '$(appServiceName)'

Output Variable: '$(armOutput.appServiceName)', you will need to reference the task name prior to the variable.

Manual Slot Swap with Azure DevOps Approvals

At this point, we now have our App Service resources deployed and the Site deployed to the production slots for Dev and Staging, and deployed to the Staging slot for Production.

But now down to the real question, how do I manually swap the slots using some Azure DevOps governance goodness?

To do this we are going to use the Azure DevOps Environment Approvals which will allow specific groups or users to approve the slot swap. Following this we will use the AzureAppServiceManage@0 task to conduct the slot swap.

Setting Up Azure DevOps Environments and Approvals

To setup an environment and approvals:

1. Sign in to your Azure DevOps organisation and open your project.
2. Select Pipelines > Environments > Create Environment.
3. Enter information for the environment, and then select Create. (For our purposes leave Resource as None)
4. In your Environment, Select Approvals and checks tab, and then select the + sign to add a new check.
5. Select Approvals, and then select Next.
6. Add users or groups as your designated Approvers, and if desired the following
   1. Instructions to approvers
   2. Allow approvers to approve their own runs
7. Make sure to Save.

Environments can be assigned to stages and jobs, but not to individual tasks. This means the slot swap task cannot reside within the environment-agnostic deployment template; it must be a separate, follow-on job.

To cater for the slot swap and environment approval, we are going to amend the orchestrating template to add another Job after the deployment Job in the Production deploy stage. This is shown below.

Adding the Slot Swap Job to the Pipeline

# Yaml
# Orchestrating Template: Build And Environment Deployments

...

- stage: 'Production'
  ...
  jobs:
    - deployment: Deploy_to_Production
      ...
            steps:
              - template: EnvironmentDeploy.azurepipelinetemplate.yml
                ...
    
    - deployment: Slot_Swap_to_Production
      dependsOn: Deploy_to_Production
      condition: succeeded()
      environment: ProductionEnv
      variables:
        appServiceName: $[ dependencies.Deploy_to_Production.outputs['Deploy_to_Production.armOutput.appServiceName'] ]
      strategy:
        runOnce:
          deploy:
            steps:
              - task: AzureAppServiceManage@0
                displayName: 'Swap App Service Staging Slot to Production'
                inputs:
                  azureSubscription: 'XXXYYYZZZ'
                  action: 'Swap Slots'
                  WebAppName: '$(appServiceName)'
                  ResourceGroupName: '$(resourceGroupName)'
                  SourceSlot: '$(slotName)'
                  SwapWithProduction: true

As can be seen in the amended template above, the Slot_Swap_to_Production job runs after the Deploy_to_Production job and expects it to have succeeded as a condition to running. The Slot_Swap_to_Production job also references the environment ProductionEnv for Approval prior to running.

Note: The first time the environment is used on the pipeline, the pipeline will ask for permission to use the resource.

Referencing Output Variables in the Slot Swap Job

The Azure App Service Manage task requires the WebAppName, which is set as an output variable in the environment-agnostic YAML pipeline template. To use this value in the Slot_Swap_to_Production job, define a new variable that references the output variable from the previous job. Once defined, you can use it within the current job as a standard variable (e.g., $(appServiceName)).

The variable reference uses the following syntax:

[dependencies.JobName.outputs[’JobName.TaskName.VariableName]]

You now have a pipeline that at the point of the slot swap job will wait for an appropriate approval prior to running and swapping your staging slot to production.

Summary

By combining Azure App Service deployment slots, Infrastructure as Code, and Azure DevOps environment approvals, you can create a robust, auditable deployment pipeline. This approach ensures that production releases are gated by manual approval, reducing risk and enabling rapid rollback if needed.

Ready to take your deployments to the next level? Try setting up manual slot swaps with approvals in your next release pipeline, and let your team experience stress-free, governed production launches.

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.

Further Reading:

Official Announcement – Microsoft Tech Community

The Bicep existing keyword is a powerful capability that allows us to reference a resource that wasn’t deployed as part of the current Bicep file.

One of the typical use cases that I often see is where a resource is deployed as part of a module called by the parent template, the resource that was deployed as part of the module is then required later in the parent template and therefore an existing resource definition is used. As part of the template configuration there would be an explicit dependency between the existing resource definition and the module reference.

An example diagram of this is shown below:

For Bicep v0.34.1 and lower, there are two scenarios that can be observed when deploying the templates:

• Scenario 1: Successful deployment. The existing resource has been found and the explicit dependency between Existing Resource and Module Ref 1 has been honoured.
• Scenario 2: Deployment Failure. The Resource XYZ under resource group 'XXYYZZ' was not found.. The existing resource has not been found and the explicit dependency between Existing Resource and Module Ref 1 has not been honoured.

For most that fall into scenario 2, without much explanation of what may be going on behind the scenes, their typical solution to this particular problem may be to force the dependency chaining by extracting further of the parent template into a further module.

An example of this can be seen below:

Yes this is a valid solution, but why is there a problem in the first place?

Explanation

It all comes down to whether your template is compiled with symbolic name code generation.

Symbolic Name Code Generation allows the ARM template layer to use a new schema to represent resources as an object dictionary rather than an array of objects. This feature improves the semantic equivalence of the Bicep and ARM templates, resulting in more reliable code generation.

In a symbolic name template, an existing resource can depend on other resources or modules, and this will cause the backend to delay reading the resource until those dependencies are completed. This allows you to deploy a resource in a module, then refer to it with an existing declaration in the module parent. In non-symbolic name templates, existing resources are compiled to reference(resourceId()) expressions and are all handled in the first wave of deployment jobs.

In a non-symbolic name compiled template the existing reference looks like this:

reference(resourceId('Microsoft.xxx/yyy', parameters('resourceName'))), '2023-05-01', 'full')

In a symbolic name compiled template the existing reference and dependencies look like this:

reference('existingResource', '2023-05-01', 'full')

"dependsOn": [
  "existingResource",
  "ModuleRef1"
]

This explains why in some template deployment cases the deployment succeeds and in others it fails (the template is not setup for symbolic name code generation). But how do you enable symbolic name code generation?

Solution

Symbolic name code generation is part of the languageVersion 2.0 functionality and can be enabled automatically by using any of the following Bicep Features:

• user-defined types
• user-defined functions
• compile-time imports
• experimental features

For most of you up until this point like me, you will have unintentionally and thankfully enabled symbolic name code generation by using features as described above and therefore not suffered from the problem case as described.

Symbolic name code generation can also be explicitly enabled by adding the following to your bicepconfig.json:

	"experimentalFeaturesEnabled": {
		"symbolicNameCodegen": true
	 }

Or the preferred option use Bicep v0.34.44 or higher where languageVersion2.0 is used automatically when an existing resource has an explicit DependsOn dependency stipulated.

If you are unsure as to whether your templates are compiled using symbolic name code generation, have a look at the first few lines of your compiled Bicep template. The ARM template should specify languageVersion 2.0 if enabled and missing this line if not.

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "languageVersion": "2.0",
  "contentVersion": "1.0.0.0",

Hope this helps and have fun.

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:

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

Hope this helps and have fun.

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:

1. Check to see if the customer is an existing customer, and if so obtain an enriched form of their details from our system.
2. Check if the time slot is available with a local driver.
3. If the time slot is available, book the time slot with the local driver.
4. 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.

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:

1. Create a Key Vault Instance.

2. Create secrets required by the application.

3. 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.

4. 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:

1. Create a Key Vault instance

2. Create secrets required by the application(s)

3. Create the user-assigned identity

4. Authorise the user-assigned identity read access to key vault or specifically the key vaults secret.

5. 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.

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:

1. 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 <app-url>/.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://<application-client-id>

   • Add the user_impersonation scope to your App Registration allowing Admins and users to consent.

2. 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'
     }
     ...
   }
   

3. 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'
     }
   }
   

4. 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.

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

   <!-- API ALL OPERATIONS SCOPE -->
   <policies>
       <inbound>
           <base />
           <!-- Uses System Assigned Managed Identity of the APIM Instance -->
             <authentication-managed-identity resource="https://management.azure.com/" output-token-variable-name="msi-access-token" ignore-error="false" />
             <set-header name="Authorization" exists-action="override">
    	         <value>@("Bearer " + (string)context.Variables["msi-access-token"])</value>
             </set-header>
       </inbound>
       <backend>
           <base />
       </backend>
       <outbound>
           <base />
       </outbound>
       <on-error>
           <base />
       </on-error>
   </policies>
   

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

   <!-- API OPERATION SCOPE -->
   <policies>
       <inbound>
           <base />
           <rewrite-uri template="__uri__" />
           <set-query-parameter name="api-version" exists-action="append">
               <value>__api-version__</value>
           </set-query-parameter>
       </inbound>
       <backend>
           <base />
       </backend>
       <outbound>
           <base />
       </outbound>
       <on-error>
           <base />
       </on-error>
   </policies>
   

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.

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.

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 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.

1. 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 <app-url>/.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://<application-client-id>

   • Add the user_impersonation scope to your App Registration allowing Admins and users to consent.

2. 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'
     }
     ...
   }
   

3. 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'
     }
   }
   

4. 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.

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

   <!-- API ALL OPERATIONS SCOPE -->
   <policies>
       <inbound>
           <base />
           <!-- Uses System Assigned Managed Identity of the APIM Instance -->
             <authentication-managed-identity resource="https://management.azure.com/" output-token-variable-name="msi-access-token" ignore-error="false" />
             <set-header name="Authorization" exists-action="override">
    	         <value>@("Bearer " + (string)context.Variables["msi-access-token"])</value>
             </set-header>
       </inbound>
       <backend>
           <base />
       </backend>
       <outbound>
           <base />
       </outbound>
       <on-error>
           <base />
       </on-error>
   </policies>
   

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.

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:

• Azure API Management | Logic App (Standard) Backend
• Azure API Management | Logic App (Standard) Backend Using a Swagger Definition
• Easy Auth | Standard Logic App with Azure API Management

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:

1. Deploy the Core Application Components.
2. Deploy the Functions to the recently deployed Function App.
3. 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<IActionResult> 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:

1. Deploy an API Management Service Instance.
2. 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:

1. 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.
2. APIM API and API Operations - Represents a set of available operations with each containing a reference to a backend service that implements the API.
3. 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.
4. 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.
5. 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.

<!-- API ALL OPERATIONS SCOPE -->
<policies>
    <inbound>
        <base />
        <set-backend-service id="functionapp-backend-policy" backend-id="__apiName__" />
        <set-header name="Ocp-Apim-Subscription-Key" exists-action="delete" />
    </inbound>
    <backend>
        <base />
    </backend>
    <outbound>
        <base />
    </outbound>
    <on-error>
        <base />
    </on-error>
</policies>

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.

<!-- API OPERATION SCOPE -->
<policies>
    <inbound>
        <base />
        <rewrite-uri template="__uri__" />
        <set-query-parameter name="code" exists-action="append">
            <value>__key__</value>
        </set-query-parameter>
    </inbound>
    <backend>
        <base />
    </backend>
    <outbound>
        <base />
    </outbound>
    <on-error>
        <base />
    </on-error>
</policies>

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.

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.

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

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:

1. Navigate to your API Management instance.
2. Select one of your APIs that you would like to Trace.
3. Select the Test tab.
4. Select one of the Operations to send a request to.
5. 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:

1. We need to obtain trace credentials using the List Debug Credentials API.
2. Enable Tracing on your API by adding the Trace Credential token as a header (Apim-Debug-Authorization) to your request.
3. 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.

4. 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:

1. Orchestrate the various Rest calls required.

2. Use variables to make as much of the calls required somewhat generic.

3. 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.

There have been few times where I have landed into this particular predicament whereby either by my own doing or through the use of another’s code base, a deep nested or thoroughly utilised (parameter/variable/or other defined item) has been created with the same name as a Bicep function. As by Murphy’s law, its only once you have reached this point of no return that you realise that your items name conflicts.

Now if you are like many in your unawares, your thoughts and actions will conclude to a singular one of ’that sucks… followed by a nasty refactor'.

Solution - Namespaces

Namespaces are a declarative scope in which identifiers such as the names of types, functions, and variables can be declared. These namespaces are used to organise code into logical groups and to prevent name collisions such as the one you are currently experiencing.

Thankfully, in Bicep there are two namespaces where all functions are split, az and sys.

• az | Contains functions that are specific to an Azure deployment such as:
  • deployment
  • environment
  • resourceGroup
  • subscription
• sys | Contains functions that are used to construct values, and decorators for parameters and resource loops. This includes but is not limited to:
  • [Array] concat
  • [File] loadJsonContent
  • [Lambda] filter
  • [Logical] bool
  • [Numeric] int
  • [String] contains

To make use of these namespaces, simply add the namespace identifier in front of the function. The example below shows a real world example of this issue where a parameter name ‘environment’ has been extensively utilised in this template and many others. This particular template is being used to deploy an AuthProvider in API Management, and the author wishes to utilise the environment function for the authentication.loginEndpoint. Without the use of the az namespace, the environment parameter would need to be refactored both in this template and wider templates for consistency.

/******************************************
Bicep Template: Function Namespace Example
Author: Andrew Wilson
******************************************/

targetScope = 'resourceGroup'

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

@description('The environment to deploy the resources to.')
@allowed([
  'dev'
  'test'
  'prod'
])
param environment string = 'dev'

...

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

var ApiManagementName = toLower('apim-${projectName}-${environment}-${location}')

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

...

// Create a new Auth Provider in APIM Credential Manager
resource AuthorizationProvider 'Microsoft.ApiManagement/service/authorizationProviders@2023-05-01-preview' = {
  ...
  properties: {
    ...
    oauth2: {
      ...
      grantTypes: {
        clientCredentials: {
          loginUri: az.environment().authentication.loginEndpoint
        }
      }
    }
  }
}

As always, have a play, and hope this helps.

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 <base /> which indicates inheritance:

 <policies>
   <inbound>
  		...
   </inbound>
   <backend>
  		...
   </backend>
   <outbound>
  		...
   </outbound>
   <on-error>
  		...
   </on-error>
 </policies>

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

  <backend>
  	<forward-request />
  </backend>

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,

1. I fixed my problem by applying the forward-request policy in my API policy definition.
2. 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.

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.

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('<connection-name>'),'/','<object-ID>')]",
   "location": "<location>",
   "dependsOn": [
      "[resourceId('Microsoft.Web/connections', parameters('connection_name'))]"
   ],
   "properties": {
      "principal": {
         "type": "ActiveDirectory",
         "identity": {
            "objectId": "<object-ID>",
            "tenantId": "<tenant-ID>"
         }
      }
   }
}

Resource Properties

Parameter	Description
<connection-name>	The name for your managed API connection, for example office365
<object-ID>	The object ID for your Microsoft Entra identity, for example the system assigned managed identity of the logic app
<tenant-ID>	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.

Over the years of developing Infrastructure as Code (IaC) with either ARM templates or Bicep (since it was released in 2020), I have made it my best practice where possible to use well-defined base type parameters (Strings | Integers | Booleans) so that the templates are usable and maintainable by collaborators apart from myself. This usually equated to where possible avoiding the use of Object and Array parameters, although in many cases the use of these types was inevitable given the complexity of the infrastructure and resources being deployed.

In the situations where I needed to make use of Object or Array parameters, I would heavily rely on defining attributes, comments, and defaults to allow the template to retain some kind of reusability and maintainability, such as:

Example: Array of Objects

@description('Array of API operations')
@minLength(1)
param apimAPIOperations array = [
  {
    name: '' // Name of API Operation
    displayName: '' // Friendly Name of API Operation
    method: '' // HTTP Method -  GET | POST | PUT | DELETE | PATCH
    lgWorkflowName: '' // Name of the Backing Logic App Workflow
    lgWorkflowTrigger: '' // Name of the Backing Logic App Workflow HTTP Trigger
  }
]

Although this approach provides nice documentation around what is expected of the parameter,

• There is no enforcement on the object structure allowing users to pass in a variation of the object causing issues further on.
• The parameter has a default value for documentation purposes, but if a user is unaware, they might use the default, again resulting in issues further on.
• There is no intellisense when using the parameter. You will completely rely on the fact that you have referenced the properties and structuring within correctly.

I promise, its not all doom and gloom, the light at the end of the tunnel has arrived…

My New Best Practice

As of December 2023 Bicep Version 0.24.24 User Defined Types are no longer experimental! Bicep CLI version 0.12.X or higher is required to use this feature.

⚠️ NOTE:

When transpiled into ARM, the user-defined types uses the new Language Version 2.0.

• The current release of the Azure Resource Manager Tools extension for Visual Studio Code does not recognize the enhancements made in languageVersion 2.0.
• The Azure Portal Custom deployment does not currently recognize the enhancements made in languageVersion 2.0.

User Defined Types allow us to define our own custom types with ambient types Strings | Integers | Booleans, primitive literals for validation (allowed options) = 'bicep' | 'arm' | 'azure' and markings for optional properties ?. There is more configurations and abilities with this feature so for more information see User-defined data types in Bicep.

User Defined Types removes my problem space. I can now create a defined type that represents my complex object or array. This new Type can then be used on a parameter with full intellisense support and validation so incorrect usage is flagged early with a Fail Fast approach.

The problem case example shown earlier can now be represented as follows:

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

@description('Configuration properties for setting up a LG App stnd APIM API Operation')
@metadata({
  name: 'Name of the API Operation'
  displayName: 'User friendly name of the API Operation'
  method: 'The API Operations HTTP method'
  lgWorkflowName: 'Name of the Standard Logic App Workflow to use for the Operation Backend'
  lgWorkflowTrigger: 'Name of the Workflow HTTP Trigger'
})
@sealed()
type apimAPIOperation = {
  name: string
  displayName: string
  method: 'GET' | 'PUT' | 'POST' | 'PATCH' | 'DELETE'
  lgWorkflowName: string
  lgWorkflowTrigger: string
}

@description('One or more APIM API Operations to configure')
@minLength(1)
type apimAPIOperationArray = apimAPIOperation[]

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

@description('Array of API operations')
param apimAPIOperations apimAPIOperationArray

The example above shows the use of:

• @description decorator to provide a high-level summary of the type

• @metadata decorator being used to document the object properties.

• @sealed decorator being used to mark the object parameter as only permitting properties specifically included in the type definition.

• Primitive Literals for Validation, the value specified can only be one of the following: method: 'GET' | 'PUT' | 'POST' | 'PATCH' | 'DELETE'.

• Union of types by creating an array type of a user-defined object type:

  type apimAPIOperationArray = apimAPIOperation[]

Have a go and see if this also becomes your new best practice. For more configurations and abilities with this feature see User-defined data types in Bicep.

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:

1. 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')
   

2. 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
     }
   }
   

3. 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
   
     }
   }]