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.
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.
- 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.
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
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 ;
And in “Workflow settings”, you can also set the basic access control settings ;
Where you can say to only allow Logic Apps or a specifc IP range.
As always, I hope this post was helpful in your journey linking together LogicApps in an even more secure manner! 😉