I have come across API and Service architectures where API/Svc gateway is positioned in DMZ for authorization/authentication of external(not employees) consumers. But, in my case, we have internal consumers also. The internal consumers are behind an intranet firewall that isolates them from DMZ. My question is do i need to deploy a separate instance of API/Svc gateway for internal users for authentication/authorization that is within intranet or should internal api access have to go through the intranet firewall to DMZ and back into the intranet?
That depends on the gateway architecture. For example Tyk.io separates UI/Portal from the gateway nodes. If the UI components and the gateway nodes are separate then you can have a single portal but differentiated gateways to handle traffic from different sources.
Related
Here is the situation :
I have a partner service outside of my network. This service is a legacy one, using soap. My internal app needs to fetch data from this service but I don't wan't to work with soap/json. My first reflex is to expose this service on my internal API gateway to consume it but ...
My gateway can of course manage transformation Rest/soap but I want to avoid doing transformation on the gateway as it is resources and time expensive.
I think of a facade component inside my network but this component will have to access public network directly and I feel this is not right.
What can I do ? Isn't it an anti pattern to get out of my network by another door than the gateway ?
there are two type of gateway
1- API gateway : which is for clients and users who need to use your APIs
2- Service gateway : in SOA or MSA your services should not call external services directly (for security reasons and also for decoupling them from each other , maybe one of them working with REST and other one working with SOAP which is your case) rather you should use something which called integration services (integration frameworks) or ESBs (enterprise service bus).
Your problem is you want to use your API gateway instead of service gateway.
Keep your API gateway for your clients but if your services need to call external services use an integration framework or a service bus.
One of the most main features of these tools is that they can convert protocols together for example they have convertors to convert SOAP to REST , it means you call it by REST but it will convert your call to SOAP and call the external service ( you just should config it to which protocol it should convert ).
And also there are many ready to use connectors in them which can connect your service bus to other applications and services like DBs, messaging platforms , linkedIn , ...... .
There are many ready to use ESBs like Apache camel , Mule ESB and .... .
I am integrating an application with database through Mule. I have exposed database queries as SOAP web services in Mule. In all there are 4 such services. These are in 4 different flows hence will be running on different ports. The problem is there is an internal firewall between application and Mule. I need to tell network administrator upfront the ports that I want to open up for inbound connections from application to Mule.
For any new service I need another HTTP port and ask for changes in firewall rules. One solution I could think of is having common entry flow (hence single HTTP port) which then delegates requests to other flows through VM or JMS transport. However I think it can be designed in better way to remove or minimize dependency on network configurations with multiple HTTP endpoints. Please advise.
If you would be deploying four different web services (i.e. 4 different WSDLs) in a JavaEE container, you would probably use the URL's path to discriminate across the services (say: /accounts /orders...).
You can achieve the same in Mule using a single HTTP endpoint and choice router, since your four services are in 4 different flows (and not 4 different applications, for which case using JMS, or the new shared VM endpoints, would be a must).
In the choice router, you can route the HTTP requests based on the http.request.path inbound property (see: http://www.mulesoft.org/documentation/display/current/HTTP+Transport+Reference#HTTPTransportReference-HTTPProperties )
I could not find a direct answer to this. Basically I have services MainService and SubService. The idea is that the Client software calls some methods in the MainService, but SubService calls another part of the service in MainService.
I am deploying to Azure and I want to have two separate interfaces in MainService, one for client and one for SubService and I don't want Client service to have any chance of access to the interface the SubService uses.
Given that I am new to WCF services, I am not sure how to approach this. Do I need multiple web roles for different interfaces that access the same database and handle concurrency issues etc. there, or can I somehow include multiple interfaces but restrict the availability by, for example, certificates. I am not exactly sure on Azure firewall rules, but if the interface in MainService that is meant for the SubService could be mapped to a separate port that would be behind a firewall rule, that would also be a viable solution.
tl;dr: Need two separate interfaces in a WCF service, one for client software (open for outer world), one for a sub-system service. Both services are to be run in Azure. What are my options?
You can use standard WCF authorization and authentication. For example: http://msdn.microsoft.com/en-us/library/ff647503.aspx
If you wanted to use Azure Service Bus with relay messaging, you could use some of the authentication and authorization provided by Service Bus. But, I'm not sure if there's any extra value there compared to just hosting your WCF in a web role (you'd have to do that in either case, but the access to the service would be decoupled from the clients via Service Bus).
Currently we run a UI web role and a web service web role(WCF REST) on Azure. Each role contains 2 instances (for load balancing and meeting the SLA reqs.)
The UI Web role and web service web role are within the same subscription but in different deployments. We do not want to merge the code bases (maintainability etc etc). So the UI layer is on xyz.cloudapp.net and the Web Service layer is on abc.cloudapp.net.
Currently, the requirement is to make the web service web role an internal endpoint i.e only accessible by the UI layer. The literature on configuring internal endpoints and accessing it from a different deployment is not very clear.
I am assuming that the two different roles need to be part of a single deployment for this to work. Can this be done without affecting the deployments? Any pointers in the right direction would be greatly appreciated.
Internal endpoints are only accessible within a single deployment, and do not route through the load balancer (so if you have 2 instances of your wcf services accessible on internal endpoint, you'd need to distribute calls between the instances). This, of course, would require you to put both your web role and wcf web role into the same deployment.
You might want to consider service bus for a secure way of reaching your wcf services from your web role instances. Or... expose the wcf services via input endpoint but secure the service.
There's an approach I like to call the virtual DMZ that sould meet your needs: http://brentdacodemonkey.wordpress.com/?s=virtual+dmz
It leverages the ACS and WCF bindings to allow you to create access control to input endpoints (which are then load balanced). Of course, if you don't want something tha robust, you can go with just a standard old WCF mutual auth scenario.
That said, David makes an excellent point. Internal endpoints are only accessible with a single deployed service. This is because that service represents an isolation boundary (think virtual lan branch) and the only input endpoints can be adressed from outside of that boundary.
Have you considered using ACS (Access Control Services) for restricting access using claims-based authentication to your WCF endpoint?
There are numerous protection schemes you could provide via WCF bindings.
Internal Endpoints can only communicate with inter-roles in the same deployment. If you have 2 separate deployments (abc.cloudapp.net and xyz.cloudapp.net, internal endpoints won't help you).
Planning to migrate our existing application to Azure.
Our existing architecture with security flow is as follows
ASP MVC 3.0 UI layer that takes user name password from the user
We are planning to migrate the UI layer onto a compute cloud.
and will be accessible at say uilayerdomainname.com which would have a SSL cert.
WCF REST webservices layer that amongst other things does authentication as well. This is currently on say servicename.cloudapp.net. (We could map it to servicelayername.com and get a SSL for that domain name as well).
SQL Azure database
The UI layer sends the credentials to the service layer which authenticates it against the SQL azure database.
Question
Both the WCF compute cloud and UI Layer are on the same region in Azure. Would the communication between these two be prone to man in the middle attacks? Does my WCF compute cloud need SSL as well? We do have two domain names with SSLs and so could just map the services to one.
Is there any way I can restrict traffic between the UI layer and the WCF compute cloud - allow only the UI layer to access the services layer?
Would the performance be better if I publish both the WCF services and UI layer on the same instance? It sort of shoots down the nice layered architecture but if it improves performance I could go with it. We don't want to jump through too many hoops to accomodate the app to Azure lest it becomes difficult to migrate out of it.
If you host your services in a Worker Role, then they can be available only to your Web Role. You can also host it elsewhere and monitor requests in code. Azure Roles in the same deployment can communicate with one another in a very specific way that is not available outside of the deployment.
In Azure deployments, you need to very specifically define your public endpoint because the roles are hosted behind a load-balancer. If you host your WCF service from within a worker-role it will not be accessible publicly.
Hope this helped
If you configure the WCF service and UI layer to only communicate through internal endpoints then the communication is private. There is no need to purchase or configure an SSL certificate for the WCF service unless it is made public.
Further, the only traffic between these internal endpoints will be between your instances -- so, the traffic is already restricted between your UI layer and the WCF service.
This is the case for both Web roles and worker roles: you can configure a Web role hosting your WCF service to have a private internal endpoint.
Depending on the architecture of your system you may see better performance if you have the UI and WCF layer on the same machine.
If your interface is "chatty" and calls the WCF service several times for each UI request then you'll definitely see a performance improvement. If there's just one or two calls then the improvement is likely to be minimal compared to the latency of your database.