Using Windows Azure Service, and exposing a WCF service endpoint from on premise (behind firewall, NAT ....) is it possible to make available an intranet site to a worker role in Azure?
Basically I want to be able to make an HttpWebRequest request from a worker role in azure to a site in on premise for example http:// intranet.domain.net. Is this possible? Or how can I make it possible?
This is not possible out of the box. You have a few options (non-trivial)
1) You will need to build a custom "proxy" that receives requests from Service Bus (over say WebHttpRelayBinding) and then forward the request to "local" IIS using HttpWebRequest or other HTTP clients. Note that this is a lot of work and needs thorough testing of corner cases (e.g. authentication scenarios). Also, it doesn't work with custom domain names (e.g. intranet.domain.net) over "https".
2) Alternatively, you can split the content/web-site and business-data/logic into separate pieces. You can host the content directly at a public site. This public site can then talk to a web-service in the intranet over NetTcpRelayBinding (or one of the *HttpRelayBinding) and execute business logic or retrieve the data.
Related
as you can see, I am relatively new on SO please don't kill me after posting this question :) I will do my best to describe the dilemma I am currently in.
I am creating something like a "Guardian Service" that is hosted on Windows Azure inside a Worker Role. This service has external ports, that can be accessed via HTTPS to allow clients to call it's service methods.
The WCF service is meant to call other services hosted in other Worker Roles that have only internal ports open, and which can be accessed only through the use of the Guardian Service. That's the main idea. Similar to a proxy or something.
I read already an excellent article from Jim O'Neil, what the caveats are when you try to access internal service points from within other WCF Services hosted in worker Roles:
His blog Troubleshooting Endpoints on a WCF Web Role
This is not the point for this question, and totally clear to me how to do that.
I have no idea at the moment, how I could do this, without implementing every contract from every single service I want to make accessible from within the Guardian Service to the outside world.
There must be a better way to decouple those things.
Any tips are appreciated.
Thank you.
I do not know the exact requirements for your project but I would say that what you are looking for is WCF Routing. I've used it in the past to redirect requests for different versions of Workflow instances.
The way it works is completely transparent to the client connecting to its endpoint. The router implementation must decide where to send the requests to, based on the request data (message headers and body).
In your case, if you are using SOAP and namespaces correctly, you might be able to base your decision on the message soap address and then send the request to the correct endpoint. You could also look at the Action property of the message.
Some links that might be useful:
http://msdn.microsoft.com/en-us/library/ee517423.aspx
http://www.codeproject.com/Articles/227699/RoutingService-on-Azure
I need to host a WCF service that will give its clients access to internal business systems on a public facing web server. Obviously I must secure this so that no one from the outside world even knows the service exists, let alone be able to call methods and access the data it exposes.
The overall idea is that the public facing website hosted on the same machine will call the WCF service and then the WCF service will provide it with the required data...
Public Facing Web Site <-> WCF Service <-> Business Systems / Databases
So I need to understand how to secure the service so it can only be accessed via the public facing website.
Ideas I had..
IIS filtering so that the IIS Site hosting the WCF service will only accept requests from a certain IP address.
Obscure port that will not be allowed through the public facing firewall.
Protocol such as NetTCP or NamedPipes
But what about the actual WCF security set up? As both the Public Facing Site and the service are on the same machine is Windows Authentication as option? Questions I have regarding this are...
Should the service client and the service simply use Windows Authentication?
Do I need specific user accounts as opposed to Network Service? If the website runs under network service would this then automatically authenticate to the service?
My objective is that someone in the outside world should not know of the services existance or be able to make access to it.
Thanks in advance.
Technical environment is: IIS7, .Net 4 and WCF 4.
I would suggest you create a http handler '.ashx' and use that as the endpoint for client requests.
If your using asp.net you can secure it by using simple forms authentication and retrieving username and password from the request headers to authenticate the request.
Then execute any requests to your business webservices which is also secured by your forms authentication.
Cheers
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).
I have a number of WCF 4.0 rest services on an internal application server which are accessed from a DMZ'd public facing web server. Essentially I am looking for the simplest way to restrict access to the services to calls from the web server and select internal accounts. It seems like a simple task of which I can find no simple answer.
Info:
IIS6 for both the web server and the application server
.NET 4
Web Server is not a part of a trusted domain
REST Services are 100% code.
Client calls are passing credentials via System.Net.CredentialCache.DefaultCredentials ( not sure if this is the way to go )
For the network part, you can disallow all IP's except the one of the ones you trust in IIS.
I have two questions I hope I can get an answer for with regard to my service oriented application
I am creating a service oriented application where controls have no events, it's all done by calling services... that means the service url is written in my jQuery code, but this seems somehow not nice.... It's like what is the best option to save service urls?! I feel it's hard to maintain and not secure when it's written inside the page or inside javascript referenced file.
I am talking to a hosting company and they told me that I can host this application services on cloud server and the application on another servers.... not all in the same server, but my application services are self hosted, I mean the services are inside the application.... so to make things work as my hosting company wants, shall I host the restful services in IIS or how exactly?
Service URL must be in your page or script source file. It can be local address unless you are using cross domain calls and JSONP - cross domain calls requires absolute address. It is the same as any other web technology. If you want navigation to other page, you must provide URL. If you want some picture or css file you must provide URL. Security is up to you.
This will be the problem of cross domain calls. Normally JS calls can be done only to the same domain where the page is exposed. Once the application server is exposed on different domain name your calls will not work. To avoid that you must use JSONP (WCF 4 has support for that). Exposing rest services consumed by your application from self hosted application is strange. REST services are consumed by your clients - they are front-end services and should be part of your application hosted on front-end web server. Your back-end application server should not host anything directly accessible by your clients.