I have a wcf service which work locally and within the network when used with the server name, this service needs to work on the internet to others outside the network to consume. I am currently hosting it on IIS. what will I need to make it available on the internet ? Do I need a DNS and SSL ? I am not sure what is required. Could somebody please let me know.
If your web service is going to be open to the public, i.e. on the internet, then you will need a domain or at least have your IP mapped to a name in DNS accessible to the public, this would require that you are self hosting the sight on you own server and have a static IP address accessible outsite your network.
Typically you would run a DNS to map your web service's IP to a domain name. However if you are going through a hosting provider they will most likely do that part for you.
Anything public facing, I would recommend using SSL over HTTPS. If the service will only be accessible to certain people, then you could use several of the different types of authentication, certificates, username/password, or tokens. There are lots of things to consider like firewalls etc.
Here some maybe helpful links to get you started:
SSL in IIS
How do I host a wcf service on the internet?
Related
I have been reading the Openshift documentation for secured (SSL) routes.
Since I use a free plan, I can only have an "Edge Termination" route, meaning the SSL is ended when external requests reach the router, with contents being transmitted from the router to the internal service via HTTP.
Is this secure ? I mean, part of the information transmission is done via HTTP in the end.
The connection between where the secure connection is terminated and your application which accepts the proxied plain HTTP request is all internal to the OpenShift cluster. It doesn't travel through any public network in the clear. Further, the way the software defined networking in OpenShift works, it is not possible for any other normal user to see that traffic, nor can applications running in other projects see the traffic.
The only people who might be able to see the traffic are administrators of the OpenShift cluster, but the same people could access your application container also. Any administrators of the system could access your application container even if using a pass through secure connection terminated with your application. So is the same situation as most managed hosting, where you rely on the administrators of the service to do the right thing.
We have a Web-Application that should interact with a desktop application that has a helper tool character (e.g. no setup, no need for admin privileges). The helper is listening via http/https on a simple port bound to localhost.
The Web-Application uses a SSL certificate. Every customer has a machine on its own for his data. For claryfication: The Web-Application is running on a server, serving one customer but multiple people.
The problem is, the Web-Application cannot reach the helper tool via https (using image or iframe). The main issue is, that the local webserver listening on localhost has no signed certificate. So the web browser is blocking the interaction.
Is there any way to get around this trouble? I think, I cannot get a certificate for localhost, because no one would sign it.
I know, that I cannot use XMLHttpRequest for this, but that's not the point.
The goal is to have a customer friendly - no install - just works - solution. The customer should not do ANY configuration. Just downloading and starting the tool. We'd like to have a direct communication to the tool (e.g. no outbound direction to the web server).
Is the any solution for this?
If it is Active-directory environment , you can create your own CA and sign certificates and distribute them across the domain. also you can add to trusted sites through domain policies this way client side you don't need to configure anything .
I have 2 web roles in a cloud service; my API and my Web Client. Im trying to setup SSL for both. My question is, do I need two SSL certificates? Do I need 2 domain names?
The endpoint for my api is my.ip.add.ress. The endpoint for my webclient is my.ip.add.ress:8080.
Im not sure how to add the dns entrees for this as there is nowhere for me to input the port number (which I have learned is because its out of the scope of the dns system).
What am I not understanding? This seems to be a pretty standard scenario with Azure Cloud Services (it is set up this way in the example project in this tutorial, for instance http://msdn.microsoft.com/en-us/library/dn735914.aspx) but I can't find anywhere that explains explicitly how to handle this scenario.
First, you are right about DNS not handling port number. For your case, you can simply use one SSL certificate for both endpoints and make the two endpoints have the same domain name. Based on which port is used by user request, the request will be routed to the correct endpoint (API vs. Web Client). Like you said this is a relative common scenario. There is no need to complicate things.
Let's assume you have one domain www.dm.com pointing to the ip address. To access your Web API, your users need to hit https://www.dm.com, without port number which defaults to 443. To access your web client, your users need to hit https://www.dm.com:8080. If you want users to use default port 443 for both web api and web client, you need to create two cloud services instead of one, then web api on one cloud service and web client on the other cloud service. Billing wise, you will be charged the same as one cloud service.
Are there any reasons you want to make 2 different domains and in turn 2 SSL certificates? If so, it is still possible. Based on your requirements, you may have to add extra logic to block requests from the other domain.
I'm trying to understand how hosting providers implementing the support for SSL.
As I know (i found many resources on web to confirm this), it's impossible to assign a SSL for more than one domain on IIS, if these domains sharing the same EP (IP:PORT).
If so, how then GoDaddy (on other hosting provider) allows me to set SSL for my site?
Does they provide IP for each hosting account? Does they provide virtual server with IP and IIS?
The question is totally theoretical and just for understanding the technology...
Thanks
If you have an SSL on Go Daddy shared hosting you are assigned a dedicated IP.
Background: Customer X is a low-budget non-profit outfit that nonetheless has a lot of activity configured on virtual hosts, and the virtual hosts multiply very frequently. Customer X also has a lot of users and is interested in getting them over to a single sign on solution. This way, all the users can use the same credentials on all the virtual hosts.
It has also pretty much been mandated that we use [Shibboleth Single-Sign-on](http://en.wikipedia.org/wiki/Shibboleth_(Internet2) to handle the authentication.
Problem: Shibboleth Single Sign On uses SSL as part of its protocol, but getting multiple virtual hosts to use SSL is not a walk in the park.
This question about virtual-hosts with SSL details some of the pitfalls.
Question: What is the best way to proceed with this scenario (summary):
multiple virtual hosts on apache
setting up a distinct IP and NIC for each virtual host is pretty much not an option
SSL pretty much requires a separate IP
they all need some kind of SSO
we are being heavily pressured to use Shibboleth as the SSO provider
Is there anything we may be missing here or some way to resolve this, short of requiring a separate IP for all vhosts?
I have a client with the exact same situation and the way that they solved it was to buy a wildcard domain *.example.com and have all the virtual hosts have a specific subdomain at example.com to get around this problem.
This was with Shibboleth and did work out, although you need the hosts domains to agree to fall under one parent domain for the SSO.
If the data itself you exchange with the given site (the Service Provider) is not security sensitive you can just turn off SSL for accessing the site.
There are two SSL channels we are talking about.
one used when the SP communicates with the IDP
the other is accessing the site
Only the latter one should be a "well-known" (what you have to pay for) certificate.
One can use HTTP artifacts to avoid POSTing data from the idp (which is SSL protected) to the SP which is not. This way the browsers security warning can be avoided.
This setup still protects user credentials. The data you exchange with the site will be not.