We need to develop integration between ERP (Dynamics Nav) and cloud-based telephony provider.
The provider needs to have an endpoint published and accessible from internet but for security reasons it is not possible for us to allow inbound connections to our network. I think it should be possible to solve this by hosting small application in Azure which will serve as endpoint for telephony provider and to which ERP will connect as outbound persistent connection. The app will just forward requests to ERP.
Since I'm new to Azure the question is what of azure capabilities I could use to solve the task aside from hosting actual VM with application there?
I've just implemented the same using Azure Service Bus.
The VOIP system is putting a small JSON with call details after the end of the call and I'll get the messages from the Service Bus Queue from NAV.
The code is not complicated at all the whole solution is simple and cheap!
Let me know if you want to know more (= you need the code).
Cheers!
Azure AD has the concept of an "application proxy" that will open internal applications up using a connector that runs on prem. This doesn't require inbound ports and is protected by Azure AD authentication.
It's intended more as a user-facing way to get access to Legacy applications, although I don't see why it couldn't be used for integration as well.
https://learn.microsoft.com/en-us/azure/active-directory/application-proxy-publish-azure-portal
Otherwise, you could link an Azure Site to Site VPN up and use a service like API gateway to manage connections though this is more complicated.
Related
We have some dedicated LOB application on-premise applications. Access to these apps is through the public Internet. Active Directory Domain Services is used to authenticate users.
In Azure, there are multiple ways to create high-availability; is there something similar for on-premise apps using Azure? By this I mean if one on-premise system is down, traffic is routed to another app.
I know there are some options such as Application Gateway, Traffic manager and Front-door including Azure LB, my question is - are these the right services we should use in an on-premise setting?
For your on premise environment, you can use Network Load balancing(NLB) feature of Windows Server. See details here, it has an Azure inspired feature too.
We have an App Service running in Azure that hosts a website. We've recently had a security review on the web site and one of the items found was that the end point below was exposed.
https://<appName>.azurewebsites.net:8172/msdeploy.axd
The recommendation is that this end point should be blocked and using a whitelist to allow limited access (e.g. the build machine that deploys to Azure). How do I block this end point?
After discussions with Microsoft support it appears that port 8172 is enabled for backwards compatibility with old versions of MsDeploy. This port is being phased out and will be open sometimes and not other times.
The fix was for us to create a new resource group, app service plan and app services multiple times until we ended up a server that had the port closed. This was frustrating but ultimately it did resolve the issue.
You could use IP level limitation in the Azure App Service access restrictions to allow limited IP addresses or VNet access to your app service. In this case, it will work on all the applications in your app service.
For some specific endpoint access control, perhaps, you need to control it with access authorization in your application code. Read Tutorial: Authenticate and authorize users end-to-end in Azure App Service and Managing access to apps.
Alternatively, you select to use Application Gateway integration with service endpoints. In this case, you only want the front end to be accessible to your end-users. The back-end should be locked down so it is only callable from the front-end. Also the front end subnet support NSG, you could restrict the end-users with IP and port to access your front end, meanwhile, it will limit access to your endpoint. See Securing Back-end App Service Web Apps with VNets and Service Endpoints for more details.
Hope this helps you.
I am getting to the point of my project where I am ready to deploy it online with my custom domain via Azure once I make the upgrade from my Free Subscription.
So a little context, I have 1 web app service and 4 api services and each one is hosted in a separate app service such as:
www.sitename.azurewebsites.net
www.sitename-api1.azurewebsites.net
www.sitename-api2.azurewebsites.net
www.sitename-api3.azurewebsites.net
www.sitename-api4.azurewebsites.net
And the above web app communicates to all 4 api's and some api's may or may not talk to another. (Would have loved an application gateway so hopefully I'll be changing this architecture later down the road).
So as I get ready to associate my domain to the services, the web container seems pretty straight forward to me as it just becomes www.sitename.com, but I am a little confused about the api services. The way I am thinking about this is that each api service will be in it's own subdomain, such as:
www.api1.sitename.net
www.api2.sitename.net
www.api3.sitename.net
www.api4.sitename.net
where I believe I can register my SSL and domain to each app service somehow, but this leaves me with a few questions.
Do I host each api in a subdomain using the same domain as the web
app, or is there a different way preferred like where I host them
all on the same domain with different exposed ports per API and web
listening 80/443, or maybe just use the IP address of the api app
service and allow www.sitename.com as the origin for CORS?
I am assuming that since I am associating my SSL cert to the web
service, I will need to do the following on the api services?
Would it be better (and still affordable) if I just had a VNET
associated to the app services and the domain only registered with
the web app?
Any insight into this would be greatly appreciated on how I can establish communication between my app services with my custom domain and SSL as I am fairly new to this part of the stack, but excited about learning!
As I known, on Azure cloud, there are two services can help to manage your APIs deployed on multiple app service containers: API Management and Application Gateway.
The Premium tier of API Management has the feature for multiple custom domain names, please see the offical document Feature-based comparison of the Azure API Management tiers as the figure below.
You can refer to the quick start tutorial of Create a new Azure API Management service instance and other related documents to kown how to.
"Azure Application Gateway is a web traffic load balancer that enables you to manage traffic to your web applications." said in the introduce What is Azure Application Gateway?. And as the figure of its architecture below, "With Application Gateway, you can make routing decisions based on additional attributes of an HTTP request, such as URI path or host headers. For example, you can route traffic based on the incoming URL. So if /images is in the incoming URL, you can route traffic to a specific set of servers (known as a pool) configured for images. If /video is in the URL, that traffic is routed to another pool that's optimized for videos."
I recommended to use Azure Application Gateway which be a good choice to manage multiple app services and expose the unified urls of APIs.
My company has several RESTful services that are behind a firewall. I would like to be able to access these services from the Azure cloud with a client app as if the service is located in Azure.
For example, if I have an on-premises url like:
https://onpremiseservice/Customers/1
I would like to be able to access it from Azure like
https://mycompany.azurewebsite.net/Customers/1.
Is this possible? Can I do some kind of URL forwarding?
Updated 26th September 2022
You have many options, here they are in order of ease of configuration vs performance (ExpressRoute being the hardest to configure but with the best performance).
Use Azure API Management it was designed for this use case.
Configure the on prem firewall so that your Azure web app outbound IP's can connect to the on prem API. Then create a Web API in the Azure web app that proxies calls using HttpClient to your on perm API.
Use a Hybrid Connection
Use Point-to-Site VPN
Use Site-to-Site VPN
Use ExpressRoute
More information on your options in depth
It is possible. Use Azure Service Bus Relays.
I have searched a lot on this topic but didnt get any satifactory answer.
In Windows Azure how can we consume an external (third party) Web Service from the worker roles? Is it as simple as using a web reference in the solution or is it necessary to use Azure Service Bus?
It's as simple as calling the webservice using whatever method you need (REST, SOAP, etc.). For .NET developers using .asmx or WCF SOAP services, just generate the proxy like you normally would. In this model, there is no difference between what you do onpremises when the cloud is the client.
You would look at using the ServiceBus when you are hosting your own services (as opposed to consuming them), typically behind firewalls onpremises, and you want to give secure access to them or integrate them into cloud scenarios. There are other scenarios and capabilities of course, but that is a main one. If you simply want to consume another web service, the ServiceBus has nothing to do with that.
As long as the 3rd-party web service endpoint is reachable, use it the same way you'd use it from an on-premises server. If you need to connect to a service endpoint behind someone's firewall, then you'd want to consider AppFabric Service Bus.
Just remember that you'll be paying for bandwidth out of the data center (unless the 3rd-party web service is Windows Azure homed, and in the same data center).