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.

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