Saturday, February 15, 2020

How to Debug and Trace request in Azure APIM - Portal, Postman, RequestBin


Introduction 
APIM is a great option to expose API's with out of box features for applying restrictions, preprocessing, postprocessing etc. You can leverage existing API's,  by importing it and it gets added as a new API with all the operations associated with it. And based on the requirements you apply policies at the stage/level (Inbound,Backend/Outbound) and you are ready to use the API.

 Before it is shared, we do some testing to make sure everything is working as per the expectation and this is where Debugging and Tracing request becomes important.
APIM does provide a way to Trace a call with the help of Ocp-Apim-Trace http header. So whichever request/call is to be traced, it needs to include this in header with the value set to true and it has dependency on another header, so that also needs to be passed i.e. Ocp-Apim-Subscription-Key

Note: The api on which Tracing is to applied , it requires the subscription key to be enabled
Read about APIM bascis -- Getting Started with Azure API Management - Fundamentals

 Let's see how we can Trace a request/call 

Tracing request/call Using the Portal


 Go to APIM instance, select any API and it's one of the operation, click on Test Tab.
Testing API using APIM Portal

Under Headers add Ocp-Apim-Subscription-key with key in the value and Ocp-Apim-Trace with value set to true.

Provide the request message in Request Body section and click on send.

testing response of api using apim portal

In Http response note that along with Message (response), Trace is also available having info from each stages (Inbound,Backend and Outboud)

Tracing request/call Using Postman


When you test with Postman, here too you have to provide the headers alongwith the request message (Body)

Tracing headers in Postman request



And alongwith the response (Body) , you are provided with location on Trace file (blob storage location). 
APIM trace testing with Postman

To see it click on Headers tab of response, and check for Ocp-Apim-Trace-Location, copy the url and paste it in browser - you should see all the traces.


How Ocp-Apim-Trace works


When we send Ocp-Apim-Trace  header in the request the APIM engine procures a temporary blog storage to store the Trace logs and associates it with the subscription key which it gets from another header which it gets in request i.e. Ocp-Apim-Subscription-Key, thus passing it in header is mandatory if tracing is to be done.

 Trace logs are JSON based, and when you test it using Portal it is fetched from the temporary file and rendered in the Trace  tab, whereas when testing with postman, the url of the trace file is returned - to which you can go and check the logs.

 Is there any other way also to Inspect the request coming to APIM?  below is one of the way 

Tracing request/call Using RequestBin


 Recently I had a situation where I had to check what JWT token am receiving with the request coming to APIM. To inspect this I used RequestBin upon suggestion of my Colleague - Manojkumar Sachdev.

 RequestBin gives you a URL that will collect requests. made to it and let you inspect them in a human-friendly way
request bin

 First go to request bin and create a bin, copy the url 
bin url
Go to APIM-->API-->Operation and click on policy in Inbound Processing section and add send-one-way-request policy


In set-body we fetch the value  of Authorization from the request header which is received to APIM and add it in string array named values and return the first value .

Now send a request and check the bin
request received in request bin

As can be seen in above image, RAW BODY has the content from Authorization header i.e. Bearer Token.

 Bearer token are base64 encoded, it consists of three main parts: Header, Payload, and Signature and separated by a dot(.). So to convert or see the token,you can use any base64 decoder available to parse the token, I have used jwt.io(https://jwt.io/) and paste the encoded token  
JWT



Related Post

ServerLess360


Posted by at No comments:
Labels:

Thursday, February 13, 2020

Securing Logic App with Azure Active Directory authentication

Introduction


In previous post - Securing Function App with Azure Active Directory authentication we saw how function app can be secured with Azure active directory and how to make call to it. And it was done by creating an AD App which acted as Audience and and was responsible for validating the access token. 

 And as Azure Function App supports AD authentication, the Audience app can be assigned/linked to it.
Securing Azure Function App with Azure Active Directory

So the first thought would be that same can be done with Logic App, why this post? - Ideally it should be but it is not because not all Azure services support Azure AD authentication and Logic App is one of them. Microsoft has a plan for adding/integrating support for all All Azure services, but it will take some time.  

 So how do we use Azure Active Directory to secure Logic App? It can be done with the help of Azure APIM, where we ask it to do the task of validating the token and rest all remains same.

i.e. whoever has to access the logic app needs to get a access token from Azure AD Tenant(Authority) in which Logic app resides and present it along with the request which will be validated by Azure APIM (using AD application's info which is created for logic App) and only after validation is done request is forwarded to Logic app. 

Thus Logic App gives away the task of security check to Azure APIM  (no code required in logic App). 


Steps to secure Logic App using Azure AD


 1. Register an Application with Active directory (AudienceAppForADSecuredLogicApp - Audience)
  • Sign in to your Azure Account through the Azure portal.
  • Select Azure Active Directory.
  • Select App registrations.
  • Select New registration.
  • Name the application. Select a supported account type, which determines who can use the application. 


Below is what you should see, make note of Application(Client) ID -- this will be used as Audience by caller app when access is requested.

AD app to secure logic app

 2. Create Logic App 

Create a simple http triggered logic app 
AD Secured Logic App
which will get triggered upon receiving http request and sends back whatever it receives as response by prefixing it with "Following is what you sent:-" . 
AD Secured Logic App

3. Create APIM Instance and Import Logic App

Read - Getting Started with Azure API Management - Fundamentals

Create APIM Instance

Now import Logic App by going to API -->Add API --> Logic App
import logic app in APIM

 Below is how it should look, an API  is created ADSecuredLogicApp having an operation manual-invoke and backend set to the imported logic app url
API Created in APIM

Note: When you add logic app as an API,you already are adding a security layer, where your logic app url gets hidden and a new url is created which is shared .

The base is ready, now we need to add the Policy in Inbound Processing Section which will validate the token

Add Policy

Select Validate JWT

Select Validate JWT Policy

Configure Validate JWT Policy in Full mode 

Configure Validate JWT Policy


 Validate by - As we are going to check header , set this to header.
Header name - name of header to be validated, set this to Authorization 
Failed validation HTTP code - what HTTP error code you want to return when validation fails, set this to 401
Failed validation error message - what error messages you want to return when validation fails
Required signed tokens? - All Azure tokens are already digitally signed so it has no effect but,set it to Yes.
Require scheme - Which authorization scheme you want, set it to Bearer 
Audiences - Against whom the token is to be validated, enter the Application ID of the AD app created in step 1
Open ID URLs - This is Authority which APIM will call internally to validate the received token, either of the below can be used

 https://login.windows.net/<tenant_name>.onmicrosoft.com/.well-known/openid-configuration

https://login.windows.net/<tenant_id>/.well-known/openid-configuration
As logic app does not understands Authorization header , we need to remove it before forwarding request to Logic App and that can be done by using Set headers policy

 Read -  The request has both SAS authentication scheme and 'Bearer' authorization scheme. Only one scheme should be used
Set Header Policy

Configure Set Header Policy
Configure Set Header Policy

 Policies should look like 
policy on inbound processing


And in code view
policy on inbound processing code view

 That's it, the Logic App is now secured with Azure Active Directory by using Azure APIM. So if someone has to access the logic App it has to present Access token and make a call to the Url set in APIM

Testing


 For testing it , have used another Logic App which will make call with access token to new URL.We need now the URL of API created in APIM (whose backend is Logic App), we can get it from Test tab as below.
new api url

Below is http based Logic app which makes call to API url and collects the response  and sends back
caller logic app
Have covered detailed steps in following post for details - Calling Active Directory Secured Function App from Logic Apps

 Using postman, did sent a request  to above callerlogicapp and received a response
testing result



How it works


As logic app is imported in APIM, an API gets created with a new URL. When a caller/client sends a request along with the access token to this url, APIM applies the policies we have set on Inbound Processing section. 

Using validate JWT token policy it cross verifies the presented token with Active directory internally (via the open ID URL) and Audience claim (against the configured audience id). 

If all ok, next policies are executed (like Set header which removes Authorization header etc) and finally request forwarded to backend (logic app). Response is collected from it and sent back to the caller/client.

If token validation fails then caller/client will be sent error message - Request is unauthorized either Access token is missing or invalid


Related Post 


ServerLess360


Posted by at No comments:
Labels: , , , ,

The request has both SAS authentication scheme and 'Bearer' authorization scheme. Only one scheme should be used

While doing testing after doing a POC on Securing Logic App with Azure Active Directory authentication, where I have put logic app behind APIM and before passing the request to logic app, apim does validation of the token.


 I was encountered with an error



"The request has both SAS authentication scheme and 'Bearer' authorization
 scheme. Only one scheme should be used."


Why it happened


After validating the token which is part of the header i.e. Authorization, APIM forwards the request as it is to backend. As  Logic app is configured as back end, it's url already consist of SAS signature plus the request also has Authorization section and this is the problem.

 By default every request endpoint on a logic app has a Shared Access Signature (SAS) in the endpoint's URL, which follows this format:

 https://<request-endpoint-URI>sp=<permissions>sv=<SAS-version>sig=<signature>

 As of now logic App only understands SAS authentication only, and there is no mechanism built yet for Authorization, thus it does not support any Authorization scheme.
Although the error says
Only one scheme should be used -- It will not work if I remove SAS part and add
only Bearer token(Any Authorization scheme)

What to do


As Logic App currently doesn't support Authorization Header, it needs to be removed before submitting request to Logic App. In my case, as I was using APIM, by using Set Header policy - the Authorization header was removed and all work fine then after.





Related Post 


ServerLess360


Posted by at No comments:
Labels: ,
Subscribe to: Posts (Atom)