Azure Federal Developer Connect articles

Calling API Management using Entra ID authentication and testing with PowerShell

JohnScott — Wed, 05 Nov 2025 23:17:52 GMT

Integrating Entra ID or other compatible identity providers with Azure API Management is both easy and a great way to enhance security for your APIs. However, when you enforce authentication with the Validate JWT policy in API Management, you now have the extra step of obtaining a JWT token from your identity provider and supplying it to API Management. If you are writing code, this is fairly straight forward to achieve with the Azure Identity libraries, and there are great API testing tools such as Postman which support integrating with an identity provider and obtaining a token and presenting it for authentication. But what happens if you happen to be in a restricted environment where tools like Postman, or even VS Code, are not available and you need to test an API? The good news is that with just a few short lines of PowerShell we can achieve the same results.

Setting up the App Registration

The first step in enabling Entra ID authentication for your app is creating an App Registration in Entra ID. There is an excellent Learn article here describing the process of setting up an App Registration and enabling the JWT validation policy in API Management, but I'll go over the rough steps here:

Open the Azure Portal
Navigate to the Entra ID blade
Go to App registrations and select New registration
Enter a name for the app registration and click register
Go to Certificates & secrets and create a new client secret
Make note of the client secret, client ID, and tenant ID
Click on the "Expose an API" blade
Click "Add" next to "Application ID URI"
Take the default URI and save the Application ID URI.

The Learn article discusses setting up scopes in the Expose an API blade but we will use the default scope in the interests of simplicity.

Setting up the validate-jwt policy

In API Management, setup the validate-jwt policy by adding the policy expression at the appropriate scope, e.g. global, workspace, product, API or operation in the Inbound policies section. While there are many options for JWT validation, e.g using claims, for the purposes of this example we'll evaluate the issuer and audience. The validate-jwt policy will look like this:

<validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized. Access token is missing or invalid."> <openid-config url="https://login.microsoftonline.us/{your-tenant-id}/v2.0/.well-known/openid-configuration" /> <audiences> <audience>{your-client-id}</audience> </audiences> <issuers> <issuer>https://sts.windows.net/{your-tenant-id}/</issuer> </issuers> </validate-jwt>

It's important to note two things here:

Even though we are in Azure Government, the issuer is still sts.windows.net (that took me down a rabbit hole once upon a time).
The "/" at the end of the issuer string is important. Failure to include the "/" will result in your validation to fail because the issuer does not match.

After you save your policy, you can test that it's working by trying an Invoke-WebRequest to your API endpoint. You should receive a 401 Unauthorized message.

Testing with PowerShell

The PowerShell script essentially has two parts. The first part obtains the JWT token from Entra ID.

$tenantId = "your-tenant-id" $clientId = "your-client-id" $clientSecret = "your-client-secret" $scope = "api://$clientId/.default" $subscriptionKey = "your-subscription-key" $tokenUrl = "https://login.microsoftonline.us/$tenantId/oauth2/v2.0/token" $body = @{ client_id = $clientId scope = $scope client_secret = $clientSecret grant_type = "client_credentials" } $response = Invoke-RestMethod -Method Post -Uri $tokenUrl -Body $body -ContentType "application/x-www-form-urlencoded" $token = $response.access_token

The second part builds the request to include the token in the Authorization header.

$headers = @{ Authorization = "Bearer $token" "Ocp-Apim-Subscription-Key" = $subscriptionKey } $outputValue = Invoke-RestMethod -Uri "https://apim.yourdomain.com/apiName/operationName" -Headers $headers -Method Get

And that's it, a simple script that will allow you to grab a token and test your APIs with Entra ID or other identity provider authentication.

Link to the script here.

Enabling the Logic Apps PowerShell Connector for performing Azure tasks

JohnScott — Fri, 24 Jan 2025 17:05:22 GMT

This is a fairly short post, but in my last post about deploying a Logic Apps Standard using Managed Identity and private networking, I'd mentioned the customer needed to run some automation tasks. Some of these tasks pertained to maintenance within their application, but some were cleaning up unused resources in Azure, specifically removing stale containers in blob storage.

However, when trying to run the Remove-AzStorageContainer PowerShell cmdlet, we got the following error: "The term 'Remove-AzStorageContainer' is not recognized as a name of a cmdlet, function, script file, or executable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again."

By default, the PowerShell Connector in Logic Apps does not include the Az PowerShell module. To enable this (or other PowerShell modules you want to use):

Open Kudu and open a CMD or PowerShell console
Navigate to site/wwwroot
Open the host.json file and ensure that you see a property "managedDependency":{"enabled":true} (this is the default and should be present).
Open the requirements.psd1 file and add any PowerShell modules and version you want installed, e.g. 'Az' = '12.*'
Save the file and restart the web service

After that, you can add the Execute PowerShell Code connector. To use a Managed Identity as the user context for performing tasks in Azure, add the following line at the beginning of your script:

Connect-AzAccount -Identity -Environment AzureUSGovernment

Enjoy!

Deploying Logic Apps Standard with Managed Identity and private networking

JohnScott — Thu, 16 Jan 2025 19:15:21 GMT

I was working with a customer who needed to implement some automation tasks to support their application. The automation tasks would be driven on data in their Azure SQL database. As most of their developers were busy tackling their backlog, I thought "What if we could use Logic Apps to do a no code solution with their operations team?"

The first step was of course to deploy the Logic App. As the customer is running fully private networking for all services (Azure SQL, Storage, etc.), we would deploy Logic Apps Standard, which runs on the Azure App Service runtime similar to Function Apps. Like a Function App, the Logic App uses a storage account in the background. However, when deploying through the portal, the deployment failed with a 403 Unauthorized error. Of course! The customer had disabled shared key access to storage accounts, utilizing Entra ID exclusively. Like our post about setting up an Azure Container Instance to use Managed Identity to connect to an Azure Container Registry, we'd have to write a bit of Bicep script to utilize a User Assigned Managed Identity which has rights to Azure Storage and SQL.

I created the User Assigned Managed Identity and granted it the following roles on the storage account:

Storage Account Contributor
Storage Blob Data Contributor
Storage Queue Data Contributor
Storage Table Data Contributor

While that solved the access issue and allowed the deployment to complete, the Logic App was showing a runtime error in the portal, stating that it was "Unable to load the proper Managed Identity."

As it turns out, we need to explicitly tell the Logic App in the App Service configuration that we are using Managed Identity as our authentication mechanism, and which Managed Identity we want to use.

Once I added that to the configuration, my Managed Identity error went away, but I was still getting a runtime error. Looking in the log stream, I could see that I was getting many errors trying to talk to the storage account queue and table endpoints. Because the client is using all private networking, we needed to setup a private endpoint and associated private DNS entry for all three storage account endpoints: blob, queue and table. Once I added those private endpoints and added them to my App Service configuration, my Logic App deployed and ran successfully.

I've added the Bicep code for the Logic App service here.

One final "Gotcha": if you look in my Bicep, you will note that I am specifying both the User Assigned Managed Identity as well as a System Assigned Managed Identity. The reason for this is, when using a SQL connector, Managed Identity was not listed as an option for authentication. I was stumped by this at first, but then I noticed that it was an option in a portal deployed Logic App. The difference was that the portal deployment adds a System Assigned Managed Identity. Once I added this to my Bicep, the Managed Identity option showed up on the SQL connector. It appears that the connector is looking for the presence of a System Assigned Managed Identity to toggle that authentication option, but you can still use your User Assinged Managed Identity for SQL authentication.

Creating a containerized build agent for Azure DevOps and Azure DevOps Server

JohnScott — Mon, 21 Oct 2024 18:51:11 GMT

In this article, we'll go over creating a containerized build agent for Azure DevOps and Azure DevOps Server. This ask came from a customer who was looking to retire their VM based build agents in favor of something that required less manual patching and maintenance. The build agent needed to be injected into a VNet, so it could communicate with the customer's Azure DevOps Server (though this works perfectly well with the Azure DevOps service) and deploy into an App Service on their VNet. The build agent needed to have the ability to build both the customer's Dotnet and JavaScript projects and then deploy them to Azure. The customer was also using an Artifacts feed in Azure DevOps for their NuGet and npm packages, so the build agent needed access to these feeds.

Attempt #1: Windows Container

Because the customer was more familiar with Windows, we decided to use a Windows based container image, specifically Windows 2022 LTSC. To this base image, in the dockerfile I added the Dotnet 8 SDK, PowerShell 7, the Az PowerShell module, Node/npm, and AzCopy. My first observation was the Windows 2022 container image started at 3.24 GB in size, and by the time we added the various packages it had ballooned up to 8.5 GB.

The next step was to upload this image to a Azure Container Registry, which took quite some time since, as previously noted, the image was so large.

*NOTE: If you do not have Docker installed, you can use the "az acr build" task to build the container image from your dockerfile and push the image to your Azure Container Registry, as I'll show in a later step.

I chose to host this in an Azure App Service, as this supported VNet Integration and is a fairly simple hosting platform for my container. I added the following 4 environment variables:

AZP_URL - the URL of the Azure DevOps Server plus the project collection (or organization for Azure DevOps service), e.g. https://devops.contoso.com/myProjectCollection
AZP_POOL - the Agent Pool name where the build agent will live
AZP_TOKEN - a PAT token that authorizes your build agent to interact with Azure DevOps. Be very careful to treat this value as a secret (consider storing it in Azure KeyVault) as it has full access to your DevOps org or collection.
AZP_AGENT_NAME - a friendly name which will identify this build agent.

I restarted the App Service so my container could pick up the environment variables, and checking in Azure DevOps Server, could see my build agent was registered in my agent pool. I created a sample dotnet application and a sample Node application to test the build pipelines. Both applications built successfully with my new containerized build agent.

Success!!! Or so I thought...

I turned the build agent over to my customer and they tried building their (larger and more complex) projects with the containerized build agent. The dotnet project restored and built without issue, but their Node application was dying on the "npm install" step with the following error: "FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory." I tried several things to fix this.

Many articles recommended adjusting Node's max-old-space-size parameter (i.e. how much memory to allocate to old objects on the heap before garbage collecting).
There's also a default memory limit for Windows Containers running on Azure App Service which are tied to the App Service Plan SKU. You can update this limit with the WEBSITE_MEMORY_LIMIT_MB app setting up to the limit of the App Service Plan.
Finally, when all else fails, scale up the App Service Plan to the maximum (these go to eleven).

While these steps seemed to lessen the effects of the problem, we were still were having intermittent failures in the pipeline runs for the "JavaScript heap out of memory" exception. Plus, running on the highest SKU available cost more than the customer really wanted to spend. Back to the drawing board.

Attempt #2: Linux Container

My next thought went to doing this in Linux. The Ubuntu 22.04 image is only 77.86 MB in size, a fraction of the Windows size, and even by the time we install PowerShell Core, the Dotnet 8 SDK, Azure CLI and Node JS, it's still barely 2 GB in size for the whole package, again about 25% of the size the Windows container had ballooned to.

After I'd created and built my dockerfile and pushed the container image to my Azure Container Registry, I tried running it in an Azure App Service, but noticed that the container kept failing post start with an error. The error indicated the service was not responding to health probes. This observation made a certain amount of sense; because there is no front end to the container, rather it's an agent listening for a signal from Azure DevOps. Well, luckily in Azure we have lots of container hosting options, so I opted to switch over to using Azure Container Instances instead.

Networking and Container Instances

One thing I immediately noticed however was that while my test container running against Azure DevOps service worked just fine, my network injected container was throwing a DNS lookup error, while trying to resolve the name of the Azure Dev Ops Server. Typically, Azure services, which are injected into a VNet, inherit the DNS settings of the VNet itself. I verified the DNS settings and found the VNet had custom DNS servers specified, so what in the container is going on here???

It turns out, in order for Container Instances to use custom DNS, those custom DNS servers have to be specified at the time the Container Instance is created. Unfortunately, the portal is somewhat limited as to what you can specify during creation, so I wrote a little bicep script to build the Container Instance. In addition to setting custom DNS, I was also able to create and assign a User Assigned Managed Identity to the Container Instance for accessing our Container Registry securely.

*As an aside, you MUST use a User Assigned, vs. System Assigned Managed Identity here if you are restricting access to your Container Registry. The reason is a bit of a "chicken/egg" problem. If you specify a User Assigned identity, you can create it and assign it access BEFORE the Container Instance is created. With a System Assigned identity, the Container Instance will attempt to pull the image as part of the deployment process and will fail before the Container Instance and the associated System Assigned identity can be created.

Once the Container Instance was deployed and running the build agent code, we were able to successfully run our build pipelines. We initially started out very small, with a single CPU and 1.5GB of RAM and did occasionally hit a "JavaScript heap out of memory" exception, but increasing the RAM eliminated this issue altogether.

Microsoft Defender for Containers and self-updating the container registry

One nice thing about having our build agents as containers is that we can configure Microsoft Defender to scan the Container Registry for vulnerabilities with Defender for Containers. While we can also scan our VM based build agents with Microsoft Defender for Servers, running in a containerized fashion gives us the opportunity to actually "self-heal" our container images by periodically re-running our dockerfile and pulling updated versions of the base OS and various packages (assuming we're not pulling specific versions of software). This can be accomplished with a couple of simple az cli commands in a pipeline.

az acr build . -r registryname -t imagename:latest --platform linux --file dockerfile #Trim the number of manifests to 1 to cleanup Defender for Container results az acr run --registry registryname --cmd 'acr purge --filter "imagename:.*" --keep 1 --untagged --ago 1d' /dev/null

Wrapping Up

I have placed the scripts and dockerfiles used in this blog in our GitHub repo here. This includes the dockerfile to build the Linux Agent, the bash script which installs the Azure DevOps agent code, my (failed) Windows version of the container, as well as the Container Instance bicep code to deploy a Container Instance with custom DNS and a Managed Identity. I hope this is helpful and please let me know if you run into any issues.

Connecting to Azure Cache for Redis with Entra ID in Azure Government

JohnScott — Fri, 04 Oct 2024 20:00:00 GMT

I was working with a customer who was trying to connect their ASP.NET application to Azure Cache for Redis, and in particular wanted to be able to connect from their developer workstation to the resource in Azure Government.

There are a couple of ways to connect to Azure Cache for Redis, either by using Access Keys or via Entra ID. Like with storage accounts and Azure Database for SQL, using static access keys or username/password authentication presents potential vulnerabilities, and using Entra ID via either Service Principals or Managed Identities provides a more robust, manageable authentication and authorization mechanism.

The Azure.Identity library provides a class called DefaultAzureCredential, which does some interesting things around chained credentials. You can read the full article here, but put simply, when using DefaultAzureCredential it will try several authentication mechanisms in order until it is able to successfully obtain a token. The order of the chain is as follows:

Environment (Essentially an Entra App Service client ID/secret or certificate)
Workload Identity
Managed Identity
Visual Studio
Azure CLI
Azure PowerShell
Azure Developer CLI
Interactive browser

What this means is that, using the same authentication code, I can authenticate in an App Service using a Managed Identity, or locally in my Visual Studio development environment using an account configured in Azure Service Authentication. I don't have to necessarily worry about how my app will authenticate in my environment so long as one of the options above is available.

Following the guidance in the Azure Cache for Redis Samples repo, the customer configured their Azure Cache for Redis connection as follows:

var configurationOptions = await ConfigurationOptions.Parse($"{_redisHostName}:6380").ConfigureForAzureWithTokenCredentialAsync(new DefaultAzureCredential());

However, when they tried stepping through the code, they would get the following error: "Failed to acquire token' - CredentialUnavailableException: EnvironmentCredential authentication unavailable. Environment variables are not fully configured. See the troubleshooting guide for more information. https://aka.ms/azsdk/net/identity/environmentcredential/"

I took a look at it and the first thing that jumped out is that we probably need to be specifying the AuthorityHost value, i.e. pointing the credential at the Azure Government cloud, like so:

var configurationOptions = await ConfigurationOptions.Parse($"{_redisHostName}:6380").ConfigureForAzureWithTokenCredentialAsync(new DefaultAzureCredential(new DefaultAzureCredentialOptions() { AuthorityHost=AzureAuthorityHosts.AzureGovernment}));

However, this did not change my error at all. So, what's going on?

It turns out, that looking in the Microsoft.Azure.StackExchangeRedis library, the ConfigureForAzureWithTokenCredentialAsync method does not yet have a way to specify a sovereign cloud endpoint (and if I'm reading the code correctly, also does not allow a ManagedIdentity to specify a sovereign cloud either). So, what now?

As it turns out, the option to use a Service Principal DOES allow you to specify a sovereign cloud to authenticate against. Creating a service principal in Entra is well documented, either in the portal as documented here, or via a simple az cli command:

az ad sp create-for-rbac --name "myredissp"

Once you have the service principal created, you can create a Redis user with the service principal in the Redis resource and connect to it in code with the following:

var configurationOptions = await ConfigurationOptions.Parse($"{_redisHostName}:6380").ConfigureForAzureWithServicePrincipalAsync(clientId, tenantId, clientSecret, null, Microsoft.Identity.Client.AzureCloudInstance.AzureUsGovernment, null);

Hopefully in the future, the option to specify a target sovereign cloud will be included to be able to use the DefaultAzureCredential to connect to Redis, but for now we can use the Service Principal.

Setting up a Point-to-Site VPN connection in Azure Government (the quick version)

JohnScott — Wed, 25 Sep 2024 15:51:44 GMT

I spent way too much time setting up a point-to-site VPN connection in Azure Government yesterday, so I figured I would do a quick blog post in the hopes this saves someone some time.

I typically setup a VPN connection between my on-prem environment to my sandbox in Azure to test network injected scenarios such as running applications on an App Service Environment, testing a SQL migration to an Azure SQL Managed Instance, etc. A point-to-site VPN is a very simple way to achieve this, but I had not yet deployed it to my government subscription. The pre-reqs are as follows:

Create a virtual network
Create a GatewaySubnet on the virtual network
Create a Virtual Network Gateway

There is a tutorial of the steps for creating these resources here.

I chose the VpnGw1 SKU for my Virtual Network Gateway (VNG) as this is just for testing and I do not require a great deal of bandwidth or number of connections, but you can size your VNG to your needs.

The next step is to setup the point-to-site. To do this, you open the Virtual Network Gateway and choose the "Point-to-site configuration" blade. The setup here is fairly simple - we add an address pool (I typically use an RFC-1918 space that does not conflict with my VNet space), the type of tunnel (we're using OpenVPN as we're doing Microsoft Entra ID authentication), the type of Authentication (which is still branded "Azure Active Directory"), and the public IP you want to use.

The next step is to add the Azure Active Directory (Microsoft Entra ID) values. Being in Azure Government, we need to consider that our endpoints are different than those in the commercial environment. The document here has a list of steps to do this, including the mapping between Azure Commercial and Azure Government endpoints. The endpoint mapping is as follows:

Tenant ID
- https://login.microsoftonline.com/{TenantID} ->https://login.microsoftonline.us/{TenantID}
Audience
- 41b23e61-6c1e-4545-b367-cd054e0ed4b4 -> 51bb15d4-3a4f-4ebf-9dca-40096fe32426
Issuer
- https://sts.windows.net/{TenantID}/

Wait. Why doesn't the issuer change? Shouldn't that go to a government endpoint too? Well, the short answer is "no." I was severely overthinking this and tried to guess at this endpoint, putting in "login.microsoftonline.us" in place of the "sts.windows.net" value, but I got the following error when I tried to connect:
[Error] Dialing VPN connection ase-vnet, Status = Server did not respond properly to VPN Control Packets. Session State: Key Material sent

That didn't help me too much so, after spending an embarrassing amount of time digging through Microsoft Entra ID, I finally had the idea to actually grab a JWT token from my tenant and inspect it. You can grab a token (I'll write a future article on how to do this) and decode it in a tool like jwt.ms. Sure enough, looking at the token, the issuer is still https://sts.windows.net/{TenantID}. Once I corrected that, my VPN client was able to connect.

There are many places in our learn.microsoft.com documentation describing the point-to-site VPN configuration process, but I feel that this documentation best describes the process for clouds other than Azure Commercial, such as Azure Government. It will walk you through authorizing the Azure VPN Application (which requires the Global administrator role in Entra ID), and how to configure the Azure VPN Client as well. Just don't do as I did and overthink the Issuer!

Using Azure Service Bus in Azure US Government

JohnScott — Thu, 25 Jul 2024 22:23:28 GMT

In our recent Azure Federal Developer Connect series, we covered connecting to Azure Service Bus using Azure Functions in Azure US Government. The process for connecting to Azure Service Bus doesn't change much for the US Government cloud, but there are a couple of nuances I will call out here. This post will walk you through the code step by step, but if you're in a hurry and just want to download the completed sample, the code is available here.

Azure Service Bus is a fully managed enterprise message broker with message queues and publish-subscribe topics. Service Bus is used to decouple applications and services from each other, providing the following benefits:

Load-balancing work across competing workers
Safely routing and transferring data and control across service and application boundaries
Coordinating transactional work that requires a high degree of reliability

What this means from a practical standpoint is that you will have some application which will publish messages to a queue or a topic, and one or many subscribing applications. Currently the Azure Service Bus client libraries support Python, C#, Java, and JavaScript, so the application communicating with Service Bus can take many forms, whether it's a C# or Python web app hosted on an App Service, a JavaScript running in a Static Web App, a containerized Java application, a no-code/low-code solution like Logic Apps - literally any application hosting mechanism which can leverage the Azure Service Bus client libraries can be used to communicate with Azure Service Bus.

For this demo I chose to use Azure Functions running C#. C# is of course a popular language, and the Azure Functions runtime allows for a lightweight, scalable means of communicating with Service Bus. Furthermore, using the Azure Functions Core Tools, we can test the function without actually needing to deploy the functions into Azure, and we can debug from our local machine, even though Azure Service Bus is running in the cloud.

The publisher application is an Azure Function using the HttpTrigger, which will use the request body of the POST and send that message to a queue or topic. The subscriber applications are using the Service Bus triggers, a ServiceBusQueueTrigger and ServiceBusTopicTrigger to read from the queues and topics, respectively. These allow us to seamlessly connect with Service Bus and instantly pick up messages as they arrive on the Queue or Topic Subscription.

Running this demo

To run this demo, you will need the following components:

An Azure Subscription
Azure CLI
dotnet SDK 8
Azure Function Core Tools
Azurite storage emulator*
A code editor such as Visual Studio Code
A REST client testing tool such as Postman

*If you are using Visual Studio 2022, Azurite is available automatically. All steps described in this post can also be accomplished within Visual Studio, as well as Visual Studio code, or from the command line using any code editor of your choice.

Create the Azure Service Bus resource

Go into the Azure Portal and create a Service Bus resource. Azure Service Bus is available in three pricing tiers: Basic, Standard and Premium. For the purposes of this demo, we will want to create a Standard tier instance, as it will support Topics. You will need to pick a globally unique namespace, and you will want to make note of your fully qualified namespace in the form of servicebusnamespace.servicebus.usgovcloudapi.net. You can accept the defaults for the rest of the configuration.

Once your Service Bus resource is provisioned, go into the resource and select the "Access Control (IAM)" blade. Add your user to the Azure Service Bus Data Owner role, which will allow your user identity to read and write from the Service Bus. If you were to deploy the functions to Azure, you would create a managed identity for the Azure Function and assign it Azure Service Bus Data Owner, Azure Service Bus Data Reader, and/or Azure Service Bus Data Writer roles as appropriate. However, for the purposes of this demo we will be testing locally and will use your Azure credentials to authenticate to Service Bus.

Finally, find the Queue blade and create a queue (in the demo this is called 'testq' but you can name it whatever you'd like). Then find the Topic blade and create a new topic ('testTopic') and one or more subscriptions on the topic ('testSubscription1','testSubscription2', etc.).

Create the Azure Functions app locally

To build the scaffolding for the Azure Function Apps, we will use the Azure Function Core Tools to first initialize the Function App, then create the skeleton for the functions themselves.

Open a Windows Terminal session and change directories to where you'd like your code to reside. Enter the following command:

func init ServiceBusQueueFunc --worker-runtime dotnet-isolated --target-framework net8.0

Change directories to the "ServiceBusQueueFunc" directory (or whatever you called your function). Then add these functions:

func new --name ServiceBusQueueWriter --template "HTTP trigger" func new --name ServiceBusQueueReader --template "ServiceBusQueueTrigger" func new --name ServiceBusTopicReader --template "ServiceBusTopicTrigger"

And finally, we need to add two libraries which will add the Azure.Message.ServiceBus and Azure.Identity libraries so we can communicate with Service Bus.

dotnet add package Azure.Messaging.ServiceBus dotnet add package Azure.Identity

Authentication to Service Bus

When it comes to authenticating with Azure Service Bus, we have a couple of choices. A simple way to authenticate is via a connection string, but this requires using a shared access key credential that you have to store and maintain somewhere, and which could be potentially compromised by a bad actor. To mitigate this, we can use the Azure.Identity library and use a managed identity for our function. Of course, because we're testing locally, we do not have a managed identity, but the Azure.Identity library will also use our Azure CLI credentials to simulate one. To login to Azure CLI:

az cloud set --name AzureUSGovernment az login --use-device-code #You may not need the use-device-code flag depending on your configuration

Configuring the Service Bus Writer Function

Now that we have the scaffolding of the Function App complete, it's time to write a little code. If you open your code editor and open the ServiceBusQueueWriter.cs file, you'll see the scaffolding code created by the Azure Functions Core Tools. As the Azure.Messaging.ServiceBus library uses Async methods, we will need to change the method to by async. Also, by default the function will accept both GET and POST requests, but as we're reading from the request body, we will eliminate the GET.

public async Task<IActionResult> Run([HttpTrigger(AuthorizationLevel.Function, "post")] HttpRequest req)

Next, we need to do is get the values for the Service Bus namespace and the name of the queue or topic we will be writing to. You can either hard code these values into your code, or retrieve them from your environment settings, e.g. a local.settings.json file.

string? fullyQualifiedNamespace = Environment.GetEnvironmentVariable("ServiceBusConnection__fullyQualifiedNamespace"); string? queueName = Environment.GetEnvironmentVariable("ServiceBusQueueName");

In the case of the ServiceBusConnection value, this will be the fully qualified namespace you gave your Service Bus resource, e.g. myservicebus.servicebus.usgovcloudapi.net.

Next, we'll add a bit of code to parse the body of the HttpRequest so we can send this to the Service Bus queue or topic.

string requestBody = await new StreamReader(req.Body).ReadToEndAsync();

And finally, we will create the Service Bus client, create a sender attached to our queue or topic, and send the message. Note on lines 1 and 2 below, I am specifying that the AuthorityHost points at AzureGovernment. By default, the authentication will be attempted against Azure Commercial.

DefaultAzureCredentialOptions options = new DefaultAzureCredentialOptions(); options.AuthorityHost = AzureAuthorityHosts.AzureGovernment; await using var client = new ServiceBusClient(fullyQualifiedNamespace, new DefaultAzureCredential(options)); var sender = client.CreateSender(queueName); await sender.SendMessageAsync(new ServiceBusMessage(requestBody));

If you get an authentication error when sending the message, you may need to add the following to your environment variables (e.g. local.settings.json) "AZURE_TENANT_ID": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

Configure the Service Bus Queue and Topic Reader Functions

To configure the Service Bus Queue and Topic Reader Functions is a bit simpler. To configure these, you simply need to add the queue/topic name and subscription (in the case of the Topic Reader) and the ServiceBusConnection.

There is a bit of a "gotcha" here. This value will be read in from your environment variables (e.g. local.settings.json) but utilizes a "magic" word in the configuration. For example, if you title your Connection "ServiceBusConnection", the value in your environment variables needs to be:

"ServiceBusConnection__fullyQualifiedNamespace": "myservicebus.servicebus.usgovcloudapi.net",

For the Queue Reader:

public async Task Run( [ServiceBusTrigger("testq", Connection = "ServiceBusConnection")] ServiceBusReceivedMessage message, ServiceBusMessageActions messageActions)

For the Topic Reader:

public async Task Run( [ServiceBusTrigger("testTopic", "testSubscription", Connection = "ServiceBusConnection")] ServiceBusReceivedMessage message, ServiceBusMessageActions messageActions)

Testing the Service Bus Queue Writer and Reader Functions

Open a new terminal window and start the Azurite storage emulator - this will run and stay persistent as long as this terminal window is open.

azurite

If you are using the command line only, you can now build the function app and start the local function run time with the following command:

func host start

If you are using Visual Studio Code, you can enter debug mode (which will support breakpoints in code) by selecting Run->Start Debugging.

When the function host starts, you should see the following:

If you are using Visual Studio Code, set a breakpoint in both the Writer and Queue Reader code. Opening your REST client tool (e.g. Postman), copy and paste the URL from the Writer function into a new POST request. In the request body, add some content into the body (you can add JSON, XML or plain text, just make sure the content-type header matches your text type).

At this point, you should be able to send your request. If you are in Visual Studio Code and have your breakpoints set, you should expect to see first the Writer function light up - go ahead and step through or hit F5 to let the code continue. If your send is successful, you should next expect to see the Queue Reader function light up. Because we are using a Service Bus trigger, the function will execute immediately when an item lands in the queue.

Testing the Topic Trigger

Writing to a topic does not require changing any code in the Queue Writer, we just need to change the destination from the name of the queue to the name of the topic. When you run your test again against the topic, this time we expect the Topic Reader function to execute. If you look at your topic and related subscriptions in the Azure portal, you should expect to see 0 messages in the subscription you are reading from, and 1 message each in the other subscriptions.

Conclusions

Hopefully this has been informative about how easy it is to implement messaging for your applications and solutions using Azure Service Bus, as well as highlighting the small nuances for using this feature in Azure Government. Future Service Bus topics may involve more advanced topics such as ordered message delivery and multi-region resiliency, but please suggest topics that you would like to see in a future post, and please bookmark Azure Federal Developer Connect and register for our upcoming sessions!

Upcoming Azure Federal Developer Connect Webinar

JohnScott — Mon, 29 Apr 2024 15:11:21 GMT

Join us on April 30th, 2024, for the Azure Federal Developer Connect Webinar with our speaker Haitham Shahin! The topic for this installment will be Container Orchestration: Managing a large number of containers and how they interact. Register today at https://aka.ms/AzureFedDevConnect!

Follow the Azure Federal Developer Connect blog at aka.ms/AzureFedDevConnect

Welcome to the Azure Federal Developer Connect Blog!

JohnScott — Mon, 15 Apr 2024 15:27:30 GMT

Greetings and welcome to the Azure Federal Developer Connect Blog! Our goal is to accelerate cloud adoption and empower every developer to innovate and build software with our platform. While the topics in this blog will reflect industry best practices and may be of interest to all Azure users worldwide, our target audience is the Federal Government developer community.

This blog is a companion to our Azure Federal Developer Connect webinar series. Please join us for our next Azure Federal Developer Connect session on April 16th. This session will cover API Management - an Azure managed service for creating, publishing, and managing API's. Register today at https://aka.ms/AzureFedDevConnect