I have a platform archicture with 3 Tiers (Presentation Tier, Application Tier and Data Tier).
I'm currently building a Web Api on the Presentation Tier with OData. I have read that microsoft is going to deprecate OData with WFC, since they don't have enough recourses to continue the project. As an alternative, I want to mascarade the 3Ties platform into 2Tiers, so that OData (on the Presentation Tier) could have direct access to Data Tier.
In order to achieve this I need a Reverse Http Proxy Server right?
Which reliable opensource/free Reverse Http Proxy Servers exists for windows?
Apache has a great reverse proxy built in (using mod_proxy). I've used it for years.
http://geronimo.apache.org/GMOxDOC11/configure-apache-httpd-as-a-reverse-proxy-modproxy.html
https://www.digitalocean.com/community/tutorials/how-to-use-apache-http-server-as-reverse-proxy-using-mod_proxy-extension
http://httpd.apache.org/docs/2.2/mod/mod_proxy.html
Related
Would like to understand what is the difference between WAF and APIM (Like APIGEE or AZURE APIM).
What are capabilities of WAF and which needs to be choose to protect the backend web application.
Thank you in advance.
Aaditya
WAF protects your backend web server by stopping every request that having malicious values. Malicious requests can be SQL injection, Cross site scripting.
Modern WAF also protects server from blacklisted IPS (tor or bots).
You can also define rules like whitelist IP or regex match for parameters and header.
Regards,
Jaikey sarraf
Google Apigee plateform also has capabilities like whitelisting, security(OAuth, JWT, Basic and key based), CORS header and others.
I think that you should more focus on what kind of architecture you might need in order to support future requirement. As with Apigee, Google has great support for cloud as well(AWS, GCP and Azure) with support to almost all type of language and virtual target backend for complex mesh ups as well.
Apigee provides inbuild support for Analytics and Monetization services as well, which you might want to consider.
Apigee has 24X7 support for all your issue/concern for different level of environments.
According to this BizTalk documentation, the HTTP receive adapter must be in the application (middle) layer. This means BizTalk is limited to a 2-tier architecture, which for modern enterprises is a pretty big limitation.
Is the reverse proxy suggestion that Microsoft recommends (on the link above) the common solution to this problem? Has anyone used any other configuration to use the HTTP receive adapter in the web/perimeter layer and been able to negotiate messages through an application layer?
If the reverse proxy method was used, were existing proxy's in the enterprise used or were dedicated proxy's configured for the solution?
I believe you are confusing application tiers with network architecture.
BizTalk is almost by definition the middle tier, implying at least a 3-tier solution. There would be the client that calls a BizTalk service, the BizTalk application itself, and some line of business application that contains most of the business logic (and then whatever database/repository that system uses to store its records). There could be more than one line of business application that BizTalk interacts with to process the client request.
The diagram and article you have referenced simply describe how you can use a reverse proxy to grant external clients access to BizTalk HTTP(S) endpoints that are hosted on your internal network.
These days it is becoming more common practice to expose the web service via Azure Service Bus Relay or API in Azure. But yes, it is was common to expose your BizTalk web service via a reverse proxy with proper security in place. If you place your BizTalk server in the DMZ, you have to poke a lot of holes from BizTalk to your internal systems, which is what you want to avoid.
Keep in mind, the "n-tier" thing is pretty much meaningless. An app can be as many tiers as you want to count.
However, in 99.9% of cases, there is no reason to put the BizTalk HTTP host or any other endpoint on the perimeter network.
Depending on local polity, shops will do either port forwarding or inbound proxy (reverse proxy isn't really a thing either ;).
There are absolutely no limits in BizTalk for way to accomplish this. How depends entirely on what your network team allows or prefers.
We have this architecture:
Web Server: Web Application is deployed (html, javascript, css)
Application Server: WebApi is deployed
Problem is , I cannot make ajax request to reach Application Server because its behind firewall.
The Web Application is supposed to be used publicly to the internet users.
What changes should we do to make it work?
Should we move our Web Application to Application Server? But how would this be accessible on internet.
Thanks in advance for suggestions/advice.
You're going to have to put an exception in the firewall for the address of your web server... that way your web server can access the API but nothing else can (well, not quite nothing else - other stuff on that web server can but that can easily be solved by having your web app hosted on it's own/dedicated web server).
If your Web Application makes direct calls to the Web API endpoint (e.g. is a single page application that use a client-side javascript framework like AngularJS and/or it uses AJAX calls to your application server address), there is no way for your clients to access your API if you do not allow public access to your application server.
That's because your client resides inside your users web browsers.
You have to allow incoming connections to your Application Server through internet in your firewall.
Well, it all depends on how you look at things and how distributed your application should be (criteria like load, security).
In general, Web API might be just one more client (from your applications server perspective).
On the other hand, in robust/distributed system, you would have Web API only as an endpoint (controllers, mappers and things like that) that your mobile/ajax clients send requests to and then Web API communicates to Application server (where your business logic is).
Having Web API communicate to DB directly is not a good idea because as you add clients to application server (mvc, web api, services, etc...) then you have as many db access points as you have clients. So, its a code maintenance problem plus a problem of your view tier being aware of DB.
Ideally, you need Application server as a tier where all your business logic is and its the one that all your clients target (mvc web app, web api, desktop, services, etc...) and that is the one that should communicate to your DAL. Also, then you can set firewall rules on your application server to allow incoming traffic from trusted sources (your other servers) instead from the whole internet (ajax).
Firstly, I'm relatively new to Web API / CORS and security implementation.
This question is specifically with regards to security. The Web API houses extremely sensitive data and provides clients with the ability to execute transactions online.
The context :
I have a Web API self hosted as a windows service with a fixed port.
The Web API is sitting behind a firewall / DMZ on an internal network.
The Web API (using CORS) only allows traffic from the external server.
The external server hosts our web site using IIS.
The Web API is making use of Token authentication (bound to client IP to avoid hi-jacking).
Both the external website and internal Web API force the use of SSL.
The problem :
The web page makes ajax calls via javascript to the Web API. However, the Web API is not directly exposed to the internet.
What would the security impact be on having the below setup?
What sort of vulnerabilities would I be exposing my network too by doing so.
Is there a better way of implementing such a setup!?
Eg
User enters https://test.mydomain.com into the browser and is served a page.
ajax call gets made to https://test.mydomain.com/api/test/action
external server routes https://test.mydomain.com/api messages to internal server https://myInternalWebAPI/api/test/action which is not exposed to the public.
So this requires a little bit of leg work, but it's implemented into a production environment so I thought I'd share the solution.
I created a WCF service and a WebAPI.
The primary WCF Service resides on the internal network and contains all the business logic, database connectivity.
The proxy WebAPI mimics the WCF service structure and is exposed to the public.
The proxy WebAPI is called from the client (javascript), the proxy WebAPI then calls the internal server hosting the WCF service and voila, victory.
Real application how can i use this app fabric ??
How can i put my business logic in this and this logic use in my windows azure application??
Thanks
The Azure AppFabric is a collection of services that allow to you leverage functionality traditionally provided on premise by infrasture components common to most networks. Currently, it consists of the following:
Azure AppFabric Service Bus - allows for connection of applications by providing a centralized relay point in the cloud. Applications create outbound connections to the rendezvous location, thus helping mitigate the challenges posed by security measures like firewall restrictions on in-bound connections and IP masking via NAT layers. This feature includes both 'real time' options as well a 'message buffer' dynamic to allow for more disconnected style communication.
Azure AppFabric Access Control Service - the "ACS" allows WIF applications to quickly access various identity providers and consume a single format of claims token. Used in conjunction with products like ADFS, it allows cloud hosted applications to authenticate against on-premise identity stores.
Azure AppFabric Cache Service - currently in public testing, this service brings the "Velocity" style functionality to applications. This provides them with a distributed cache system as well as a new session provider.
There's more features/services coming in 2011, but these are the hot ones currently. Regarding hosting your business logic, this is not something that is currently available in the Azure AppFabric. There's been mentions that we may eventually see the potential for placing applications "on the edge", meaning the servers that front the Azure AppFabric connections, but no ETA or even firm commitment that this will happen.
You can implement your business logic in Windows Azure, in a web or worker role depending if you need it to be synchronous or asynchronous.
You can surface the business logic using the service bus, though you could also implement your logic on premise and surface them via the service bus.
AppFabric is not a business logic layer. Think of AppFabric as cross-cuts, or glue between different parts of your application.
For now Business logic goes in components like a web or worker role, or an on premise app which you could expose on the internet using AppFabric Service Bus.
In a future release, AppFabric will release "Composite Apps" which in a nutshell seem to allow you to deploy managed WCF/WF workflow services, which makes for a better "business engine". But for now I think you could probably just use Workflow services in a web role.