I have two flows, both have gateways. One of the flow has outbound gateway to webservice. The second flow should connect to first one. Problem is that I dont know how to do it correctly.
Once your provider is up and running, in the consumer side, What you need is a web service inbound gateway
Bare minimum example (assuming you have imported ws namespace):
<ws:inbound-gateway id="myInbound" request-channel="myRequestChannel"/>
You will also need to configure your web.xml file, so that incomming SI specific requests are handled by MessageDispatcherServlet.
For application layer abstraction, I will also add a generic gateway listening to the same channel.
Related
Is it possible to include a separate Azure App Service as part of another App Service?
For example lets say that I have a website called www.mycompany.com hosted in its own Azure App Service. I have another Azure App Service that I want to make it accessible by going to a specific URL in the first App Service.
So in other words when a request comes to www.mycompany.com/eu/ I want the content of this endpoint (/eu) to be served from the other app service. Would a load balancer work? The reason I want to do this is because the /eu endpoint has grown too big and I would like to separate that from the main site and host it on a separate app service. I hope my question is clear.
Thanks in advance.
For this purpose you could use Application Gateway.
In a certain sense it resembles a load balancer (it is a L7 LB indeed) as you indicated, but the product provides many additional features.
The following image, extracted from the product documentation, explains how it works:
Basically, as outlined in the aforementioned docs, when describing how an Application Gateway accepts a request (note they mention WAF in the explanation, an optional security threat prevention system):
Before a client sends a request to an application gateway, it
resolves the domain name of the application gateway by using a Domain
Name System (DNS) server. Azure controls the DNS entry because all
application gateways are in the azure.com domain.
The Azure DNS returns the IP address to the client, which is the
frontend IP address of the application gateway.
The application gateway accepts incoming traffic on one or more
listeners. A listener is a logical entity that checks for
connection requests. It's configured with a frontend IP address,
protocol, and port number for connections from clients to the
application gateway.
If a web application firewall (WAF) is in use, the application
gateway checks the request headers and the body, if present,
against WAF rules. This action determines if the request is valid
request or a security threat. If the request is valid, it's routed
to the backend. If the request isn't valid and WAF is in Prevention
mode, it's blocked as a security threat. If it's in Detection mode,
the request is evaluated and logged, but still forwarded to the
backend server.
The routing to one backend or another can be based on URL Paths:
You can find an example of this configuration in this related Microsoft article.
In your use case, you will need to define two backends, one for every App Service, and define routing rules as appropriate.
As indicated before, your DNS should point to the Application Gateway: it will handle the routing to one or other App Service based on the route, /eu/* or /*, provided by the client.
The order of the routes is important: once a rule is matched, it will be the one processed.
Application Gateway is a regional service: Azure Front Door leverages a similar functionality (and much more) globally.
Please, consider review the associated costs of these services.
I am answering my own question to hopefully help others in the same situation. This was simply done using a reverse proxy. This article explains everything you need to set it up - https://ruslany.net/2014/05/using-azure-web-site-as-a-reverse-proxy/
I have a light-weight function running in an Azure Function App. The function connects to an API endpoint over the internet as illustrated in the following diagram. It will always be outbound connections only.
My question is do I need to use a web application firewall in front of the Azure Function?
Simple answer: No. A Web Application Firewall is in most cases used to filter inbound HTTP traffic. Unless you are afraid of something hijacking your Function and making malicious outbound calls, you don't need that here. And as your Function doesn't have inbound HTTP calls, I really do not see a need for that.
Your external API provider might have a WAF in place, but that is nothing you need to care about.
Should an app have a single Gateway for all users and switch to the relevant identity for requests, or multiple Gateways (one per user) with identity initially set and never changed?
Should the Gateway be connected and disconnected after each request, or should it be initially connected once and left open?
The following applies to v1.4 of the node implementation of Gateway in the fabric-network package.
You should have a single gateway for each individual user. Once you disconnect a gateway you should not use it again (ie don't attempt to call connect again).
A basic pattern for multi-user apps that are long running would be to create a gateway for each user and cache it. Use a stale policy to disconnect and disgard that gateway if it hasn't been used for a while by the user.
#here, please help me understanding microservice authentication with API Gateway.
Let's take an example - I have 10 different independent deployed microservices and I have implemented the API Gateway for all of them meaning all the request will be passed through that gateway, also instead of adding authorization/JWt in every microservice I added in API Gateway with this approach all is working fine, but my doubt and question is
1 What if an end user has the URL of deployed microservice and he tries to connect it without gateway (as I don't have the authorization place here, how do I stop this, do I need to add same authorization logic in every microservice as well but that would end in duplicating the code, then what is the use of API gateway.
let me know if any other input required, hoping I explained my problem correctly.
Thanks
CP Variyani
Generally speaking: your microservice(s) will either be internal or public. In other words, they either are or are not reachable by the outside world. If they are internal, you can opt to leave them unprotected, since the protection is basically coming from your firewall. If they are public, then they should require authentication, regardless of whether they are used directly or not.
However, it's often best to just require authentication always, even if they are internal-only. It's easy enough to employ client auth and scopes to ensure that only your application(s) can access the service(s). Then, if there is some sort of misconfiguration where the service(s) are leaked to the external network (i.e. Internet at large) or a hole is opened in the firewall, you're still protected.
API gateway is used to handle cross cutting concerns like "Authorziation", TLS etc and also Single point of entry to your services.
Coming to your question, If your API services are exposed for public access then you have to secure them. Normally API gateway is the only point exposed to public , rest of the services are behind firewall (virtual network) that can only be accessed by API gateway , unless you have some reason to expose your services publicly.
e.g. if you are using Kubernetes for your services deployment, your can set your services to be accessible only inside the cluster (services have private IPs) , and the only way to access them is API gateway. You don't need to do anything special then.
However if your services are exposed publicly (have public IPs) for any reason then you have to secure them. So in short it depends how you have deployed them and if they have public IP associated with them.
Based on your comments below. You should do the authentication in your API gateway and pass the token in your request to your services. Your services will only authenticate the token not redo the whole authentication. This way if you want to update/change the authentication provider or flow , it's easier to do if you keep it in API gateway.
I have a virtual machine on Azure which will listen to messages over the servicebus of Azure. And another developer needs to connect to this servicebus to send messages to my service. To do so, we need to come up with some protocol for this communication system. And I was thinking about using WSDL to make the server something webservice-like, but instead of listening to the standard HTTP ports it would connect to the service bus and within it a topic with subscription, or whatever. I'm still not sure what would be best.
So, is it possible? Has anyone done something similar before? Are there some examples?
Service Bus provides both Brokered and Relayed messaging models. With using Topics/Queues you are essentially sending and receiving message to/from the broker. So you can use APIs/protocols that the broker supports. As an example you can use the NetMessagingBinding from your service/client to send and receive messages through the queue. There is no contract here other than what you put in the BrokeredMessage body and properties values. The application on either end can decode/decipher that info as needed.
In the case of Relayed messaging however you are making a end-to-end connection between the client and the service with Service Bus serving as the proxy in-between for auth, location-transparency and even load-balancing. So here you can use from a variety of RelayBindings such as NetTcpRelayBinding or webHttpRelayBinding but then both the client and the service need to be available at the same time. Here you need the service and clients to be using the same contract.