I am looking for some design guidance in using Azure APIM as a forward proxy between backend services (such as function apps or logic apps) and external clients.
We have a function app that processes invoice requests (for an order previously placed) from a mainframe system, does some transformations and sends them to an external party via HTTP. I have two options with the sending process.
Store external HTTP endpoint as an app setting in function app and let function app send the
transformed message directly to external party.
Send the transformed message to Azure APIM with the external HTTP endpoint set as the backend service (using set-backend-service APIM policy) and let APIM forward it to external party.
Now, are there are any real benefits with the second approach if the requirement is only to forward requests to external party from a security or operational standpoint? There are no requirements to enrich the outgoing message (add or remove headers, modify message body etc).
Personally, all I see is an extra hop with the second approach. But some of my teammates seem to think the second approach can offer some benefits in the way of analytics. There are some metrics available under APIM --> Analytics tab that lets you see the number of successful, failed requests etc. But I think this information is also available to Application Insights tied to the function app.
Just interested to see some insights around this so we can make an informed decision.
I guess using Azure API Management would be an over-engineering in your case, assuming the Azure Function is only going to be the caller of the Azure API Management instance.
Even though Azure API management provides analytics, url-rewrites, transformations, analytics etc - it makes more sense when you use it to govern the API. Ask yourself a question on, how many of the Azure API management functionalities are going to be leveraged fully in your case.
Remember Azure API management by design is an API governance tool where you can perform throttling, monetizing your API by giving access to it to different 3rd party with segregated subscription keys. In my opinion, Azure API management comes into the scene where you need to distribute some API to 3rd party applications, which clearly not in your case.
Related
I am trying to build an Azure Durable function to orchestrate the execution sequences between multiple azure functions. Sometimes few of those functions are required to be executed parallel, sometimes in sequence. Its all based on some JSON configuration files.
But I am expecting my durable function being called by more than 1000 consumers and this every minute there is a probability of 1000 hits to the durable functions end point. Since internally durable function uses queues and tables, individual calls from durable functions will be organized, but what are the solutions available in azure to manage the situation of large number of hits in this durable function's API endpoint.
You can go through this load balancing solution documentation in Azure to decide on best load balancing solution to use in your case.
Given if it is a HTTP based application and based on the service provided, you can take a look at
Azure FrontDoor: It is a modern cloud CDN solution which provides fast, reliable, and secure access between your users and your applications’ static and dynamic web content across the globe. You can enable caching on the frontdoor to reduce the calls made to your backend. You can also secure your application with WAF.
Azure Application Gateway: It is a regional load balancer for a web application, where you can take advantage of features like WAF, auto-scaling, URL based routing etc.
Based on your requirements you can use both application gateway and front door together, more information can be found here.
I have an Azure logic app that uses a Custom Connector that I've made from importing a Postman Collection. The RESTful API that my connector calls require 3 authentication headers in each request: UserName, Secret, ApiIntegrationCode. Because it takes three specifically named parameters, I don't believe that any of the authentication presets will work for me.
I know that I can protect the inputs and outputs of various connectors. I have been entertaining the idea of storing the sensitive information in a SQL table that I query in each run and storing the values in variables that I pass to each of my custom connector's API calls.
Would this be a viable way of protecting sensitive data from being seen by people that may have access to my logic app? What is the most secure way I can pass these headers in each call?
There are not too many options within a (consumption) Logic App in this regard.
Your options with Logic Apps
A first step into the right direction is to put your sensitive information into an Azure Key Vault and use the corresponding connector in your Logic App to retrieve the data from there. This is easier to implement and more secure than querying a SQL table for this purpose.
The second thing you can do is to activate secure inputs for the connectors that make the API calls. This makes sure, that the sensitive information passed to these connectors is obfuscated in the run history of your logic App and in connected services like Azure Log Analytics.
The problem with this approach is, that anyone who has more than just read permissions to your Logic App can just go ahead and deactivate the secure inputs setting or create a step that dumps the content of your Key Vault. You can use RBAC to control access to your Logic App but that means of course administrative overhead.
Alternative: API Management Service
If you want by all means to allow other developers to change the Logic App without exposing API secrets to them, you might consider using some sort of middle tier to communicate with the API. Azure API Management Service (APIM) is one of the options here.
You would manage your sensitive information in a Key Vault and inject them via "Named Values" into your APIM instance. You can then add your API as a backend in APIM and expose it towards your Logic App.
The advantage here is that you can secure access to your API with APIM subscription keys that you can cycle frequently. You can also restrict the access to the original API to only those calls, that need to be available to the Logic App.
If APIM is something for you depends on your use case, as it comes at a price. Even the developer plan costs about $50/month: https://azure.microsoft.com/en-us/pricing/details/api-management/
Alternative: Azure Function
You can use a simple Azure Function that serves as a middle tier between your Logic App and your API. This function can be configured to pull the sensitive data from a Key Vault and can also be secured via a function access key, that you can renew on a regular basis.
This is a dirt cheap option, if you are running the functions on a consumption plan: https://azure.microsoft.com/en-us/pricing/details/functions/
i have question regarding Azure API Management again : ).
i am using API management which is API Gateway doing HTTPS to Azure Storage REST API directly
and is there any way that i cant get email notification when there are massive requests or high latency at response ??
Thanx for reading : )
You can configure alert notifications either in the portal or via the REST API or .NET SDK to monitor for specific Azure Storage Metrics that you want.
See https://azure.microsoft.com/en-us/documentation/articles/insights-receive-alert-notifications/ for more details.
For massive requests, you might want to consider using "TotalRequests" or "TotalBillableRequests" in a specific time period.
For high response latency, you can track "AverageE2ELatency" or "AverageServerLatency" in a specific time period.
See https://azure.microsoft.com/en-us/documentation/articles/storage-monitoring-diagnosing-troubleshooting/#monitoring-performance for more details on these specific metrics and how they relate to performance monitoring.
Hope this helps.
Sriprasad's answer makes sense for configuration from the Storage side. From the API Management side, you cannot currently set a notification on any event other than the built-in ones (subscription requests, new subscriptions, application gallery requests, new issues/comments, approaching of user subscription quota limit).
You can use Log-To-Eventhub policy to log a message to event hub for every request and consume it in a custom or third party solution like AppInsights/Runscopee to fire an alert.
Refer
https://azure.microsoft.com/en-us/documentation/articles/api-management-log-to-eventhub-sample/
If your requirement is to get report/metrics from API Management you can use the management rest api's for APIM.
https://msdn.microsoft.com/en-us/library/dn781421.aspx
Specifically you might want to look at reportByAPI (which gives you useful metrics in response like callcounts, apiTimeAvg) based on which you can setup alerts/email notification.
https://msdn.microsoft.com/en-us/library/dn781421.aspx#ReportByAPI
I have a question about the use of the Azure Management Api. The architecture of the single responssabilidade Api predicts domain to perform the functions of the business area. See image structure.
enter image description here
1. I wonder if the Azure Api Management operates as a management or I have the possibility of using it as a Geteway add results of many APIs in one (
orchestrating) and available to the client that made the request?
2. The responsability to gather this data is the Web Application?
3. Is there a pattern?
Azure API management can do both, it started as a management tool, but has received some updates so it can act as a gateway as well.
Read about the different API managment policies you can create here: https://azure.microsoft.com/en-us/documentation/articles/api-management-policy-reference/
Or take a look at the advanced policies, with the control flow and the send request
https://msdn.microsoft.com/library/azure/dn894085.aspx
For an example of sending requests to gather information from multiple sources see this:
https://azure.microsoft.com/nl-nl/documentation/articles/api-management-sample-send-request/
So I have a mobile app that uses AWS's IAM infrastructure that effectively allows me to provide temporary access tokens to anonymous mobile devices, so that they can run queries against AWS services directly from the mobile device.
Does anyone know if Windows Azure has a drop in replacement for this sort of thing too? I've read about Windows Azure Access Control but all examples seem to focus on allowing authentication via the likes of Facebook, Twitter or Windows Live etc. In my case, I don't want the mobile user to have to "log-in" anywhere, I just want them to be able to access Azure services such as table storage, without having to go via my server.
Thanks!
You do have the ability to create Signed Access Signatures for all three Windows Azure Storage services (BLOBs, Queues and Tables) as well as for Windows Azure Service Bus Brokered Messages (Queues, Topics & Subscriptions). These SAS urls are temporary and you can create them ad-hoc with expiration times. After that time expires the device would have to request a new one, likely from your server. This reduce the load as they aren't coming back all the time, but you do still have to run something that will gen these SAS uris for the devices. You can generate SAS manually against the REST API direct, or you can use one of the SDKs to generate them for you (which also hit the REST API).
Note that when you create a SAS you have the option of doing so as a Policy, or adhoc. A policy allows you to revoke a SAS at a later time, but you can only have so many of these defined at a time (likely too big of a restriction for a mobile scenario if you are doing by device). The adhoc approach allows you pretty much as many as you need (I think), but you don't have the ability to revoke it, it just has to expire.
Another option is to look at Windows Azure Mobile Services. This service runs on servers managed by Microsoft and you can use it to get at just about anything you want. You'd want to look at the "Custom API" feature. Also, make sure you understand the pricing model of mobile services (or really, that stands for any option you decide to go with).
It's called managed identities in Azure