Identity based security for LogicApp to LogicApp communication

Introduction

For today’s post we’ll go through a simple (yet powerful!) example that shows you how to securely communicate between two LogicApps. For this we will leverage the concept of managed system identity on the sender and access token validation on the receiver.

Conceptual

To get a bit of an idea of the flow, let us take a look at the drawing below…

The sender (LogicApp on the top left) is foreseen of a Managed System Identity in AAD. It will leverage this capability to get an access token from AAD. In addition, we will include a specific audience in the scope. This refers to an application object inside of the AAD tenant.
This token will then be included in the authorization header (as a JWT token) towards the receiver (LogicApp on the top right). The receiver will validate the JWT token by checking the public keys of the issues (AAD). Next up, it will check if the Issuer and Audience provided match the defined policy. If all is okay, then it will accept the request.

Supporting Documentation

Secure LogicApp Access ; https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-securing-a-logic-app
Authenticate with Managed System Identity ; Authenticate with managed identities – Azure Logic Apps | Microsoft Docs

Lets delve into it!

First up… Let us create an “Enterprise Application” in AAD ;

We will use this one later on as the “Audience”. So do write down the Application ID. 😉

Next up let I created three LogicApps ;

kvaessend ; the one that will send a correct request
kvaesnaughty ; the one that will send a request with a token that does not include the correct audience
kvaesrecieve ; the one that will receive the request and validate the token

For “kvaesreceive”, I created a very simple LogicApp ;

Do note down the “HTTP POST URL” that was generated upon saving the LogicApp ;

Save that one and omit the SAS token (2nd line in the image above). Now, where I mentioned this was a simple LogicApp, it comes packing with a punch! As it has an authorization policy set ;

So it will validate the issuer (https://sts.windows.net/<insert-tenant-id>/) and the audience of our enterprise application that resides in the specific AAD tenant.

For “kvaessend” (and “kvaesnaughty”) we will create a LogicApp that does an HTTP send. Here we will select the POST-method, add the url (without SAS token!) and select “Managed Identity” as an authentication type. In addition, we also include the application id of our enterprise application as the audience.

Next to that, we enable the Managed System Identity by switching the status button on the “system assigned identity” to on.

Once done, we will see those popping up in AAD too… 😉

(Note ; In the screenshot above I also had enabled the Managed Identity for “kvaesnaughty” too. Though this is not needed for our little scenario/test!)

Now let us put this one to a test! Bingo!

Where if we go check the inputs, we can also see that the Managed Service Identity was used in addition with providing the audience. Where we see that the request was successfully received on the other end too.

Troubleshooting

Now what if things go wrong? Let us take a look at a few examples ;

Scenario ; No Audience given

If you do not provide an audience, but the authorization policy is set to validate one…

Then you will get a “MisMatchingOAuthClaims” error ;

Scenario ; SAS Token with Authorization Policy

If you provide a SAS token, and the authorization policy is set …

Then you will get a “DirectApiRequestHasMoreThanOneAUthorization” as an error ;

Scenario ; Audience does not exist in tenant

If you provide an audience that does not exist in the tenant, then you will get a BadRequest that basically highlights that your audience does not exist.

One more thing…

Want to add network access control on top of the identity security layer? Be aware that you can fiend the IP addresses used in the “Properties” of the LogicApp ;