We have a classic asp.net web API service running on Azure VM(IIS) and its configured as back end pool in azure application gateway, and the API service is running on windows NTLM authentication (in order to support some backward compatibility and dependency on a legacy component).
One of the controllers in the API is for uploading service. and it’s working fine while I’m calling the service using Insomnia/postman directly through app gateway endpoint.
But when I’m trying to consume the same app gateway endpoint through a .Net core client application. its always unauthorized. The app gateway is not sending the NTLM header to the back end pool
Here is the client code that I used to consume the service
After a long day of digging to the problem with Application gateway and IIS log. Finally, I was able to figure out the issue. Problem is primarily related to .Net Core HttpClient .
HttpClient was failing to send the NTLM header details while calling PostAsync method with multipart form data. So rather than calling PostAsync I have to use SendAsync method in following way after disabling SocketsHttpHandler
Related
We have a Blazor (WASM) application calling a .Net Core API secured by Okta. We have another common API that we plan to keep internal but have it secured by client certificate. The .Net Core API will call this common API to get some data. All of these apps are hosted in Azure (Private ASE). I understand I will need to setup a client cert and upload it to the App Service of .Net Core API and then enable client certificate authentication on the Common API App service. Now, when the .Net Core API calls the common API, how would azure know to forward/send/attach the client cert I have uploaded to the .Net Core API to the Common API? Or does it always forward all client certificates that exist on the machine where a private key is present? If this architecture won't work, should I be using Azure API Gateway here?
I have an API that runs on an Azure app service which is exposed through Azure API Management. Is there a way to tell if any requests are hitting the app service URL directly without going through the API Management service?
In my opinion, apim can't record those requests which hitting the app service url directly because these requests have no relationship with apim. If you want to record these requests, you need to modify the api in your code.
For example, you can add a parameter with a specific value in api management and when your code recieve this parameter, you can check the value to know if it comes from apim.
I assume that you want to prevent calling the app service url directly. So I suggest you adding White list on your server so that only apim request can visit your server.
For adding access restriction, if you're using azure app service, you can learn about this ms document.
I believe if you were to enabled Application Insights on both the API Management and APP Service you can view the requests on Application Insights for the APP Service to tell which ones were direct calls and which ones came from API Management.
I've created a web application API with a swagger interface that I've deployed as an API App to Azure.
When creating a Logic App I can find my API App but whenever I try to use it I get the following error:
Failed to fetch swagger. Ensure you have CORS enabled on the endpoint
and are calling an HTTPS endpoint.
I'm using the default https url for the API definition in the API App:
https://microsoft-SOME-LONG-MS-INTERNAL-ID.azurewebsites.net/swagger/docs/v1
The swagger docs have been provided in my C# web API application through Swashbuckle.
For CORS I've set a single * item.
This didn't seem sufficient for the Logic App to access the API App I then configured Authentication / Authorization for the API App to use Azure Active Directory (express), creating an AD Azure App.
I believe the issue will be one of configuring security which is all pretty new to me in Azure. I'd like to make the API App inaccessible externally, but available to Web Apps and Logic Apps within my Azure subscription.
I've not added any authentication mechanism to the ASP.NET web application itself as I figured the web application would effectively be sitting in a private network on Azure. Perhaps this is a bad assumption and I need to add authentication to allow Azure AD to work?
Any pointers / suggestions?
Turns out I needed to update the Azure SDK for Visual Studio. I had an older version that was deploying a preview Api App which resulted in a "Api app host" type being deployed rather that an "API app" type.
Everything works after the update and I've found some documentation for securing the API App and making it available in the Logic App - https://azure.microsoft.com/en-us/documentation/articles/app-service-logic-custom-hosted-api/
I have an Azure solution containing an MVC application, hosting some Web API controllers that constitute a RESTful API, and a back end WCF service. The MVC app is on a Web Role with a public http endpoint. The WCF application is on another Web Role, with no public endpoints. The MVC app communicates with the WCF service using a ChannelFactory over a discovered internal http endpoint.
I would like to keep this configuration, but I need a component within the WCF service implementation to be able to call a method on the RESTful API, using HttpClient.
My question is: with only an internal endpoint, does my back end web role have the connectivity to allow HttpClient to work like this?
At first glance I would not expect it to, but I note that it does have the capability to use the Azure Storage Client library to obtain resources from Azure Blob and Table storage, and I believe these calls are executed using http to an external URL (unless Azure does something clever to enable these calls under the hood).
Internal endpoints are for inbound traffic. Your WCF service, in turn, can absolutely make outbound calls. As you've already noticed, you're using the storage client library, and storage is a separate endpoint (RESTful, in fact), not a part of your deployed cloud service.
I have a Windows Azure Mobile Service up and running, however, there is a need for that service to consume some data expose through an external SOAP service and store that information in the mobile service database.
I would like to set up a worker in the mobile service, so the calls to the external SOAP service are executed in a fixed period of time.
I've been looking for a solution to this problem, but haven't found anything yet. So any help that would get me in the right direction would be appreciated.
Unfortunately there isn't an easy way to talk to a SOAP service from your Mobile Service backend. The backend is based on Node.js, and even though there are some Node modules for talking to SOAP services, they are currently not supported in Mobile Services. We are working on a solution that will enable you to use any Node module in your service, but it is not out yet.
If you control the SOAP service and it is written using WCF, you may be able to easily add a REST endpoint to the service with just a few config changes and then consume it from your Mobile Service via plain HTTP requests by using the "request" module.