I created a Azure Service Fabric Web API and planned to reach it through Service Fabric's built in Reverse Proxy.
All was working well locally but when I published to Azure, trying to access the route through Reverse Proxy would time out.
I thought it might be my app, so I just popped open a new solution with the default template and published to my local. Everything worked fine Reverse Proxy and all. So I published to Azure and again had the same issue.
I could access the Web API on azure through the normal route (through the endpoint of the service) for example:
xxxx.east.cloudapp.azure:8080/api/values
But going through the Reverse Proxy port of 19081 times out:
xxxx.east.cloudapp.azure:19081/[app]/[service]/api/values
I did make sure to tick off Enable Reverse Proxy when setting up the cluster resource on Azure, and set the port to 19081. Both of the above works fine on localhost, but only the normal route works on Azure.
Was wondering if there's some extra editing of the manifest or something I had to do to make it work on Azure correctly?
Did you see the documentation on how to configure it?
If you're going to expose services on the internet, be aware that the built-in one causes every service to become exposed, it's not hardened, it's vulnerable to DOS attacks.
Docs
I recommend having a look at Traefik as a reverse proxy and load balancer.
You can run it as a (containerized) ingress routing service inside the cluster, and direct HTTP calls to your services.
Here's the documentation.
Here's how to get started.
Here's an example.
Alternatively, you can use Api Gateway, which integrates with SF too.
Or even Nginx.
I would like to create a self hosted webapi that is reachable over https (ssl). I am a little bit confused because I see many different ways to do this. I read something about Karma and owin. As I know Owin is the current way to do this. Ao I implemented the first test with http and everything looks fine. But now I would like to use https. I read that you have to bind a ssl certificate to ip and port. To do this I should call netsh. But I have multiple customer machines where this service has to run. Is there any way to do it automatically in code? I mean why should I have to do it manually?
An SSL cert has to be bound to either a specified host name, or a specified IP address. So if you're installing on several machines, by definition, you'd need multiple SSL certs for your approach to work. You might be able to dump the cert files into a common folder and let your application sort out which one to apply, but you're going to need more than one.
What'd be cool would be if you could call an appropriate API to tell Windows to generate a new cert at run-time!
For my Xamarin.Forms application I've created a ASP.NET Web API as a backend to handle serverside stuff.
When it comes to security I'm pretty much lost.
I've read alot of articles containing alot of possibilities such as HCMA, OAuth and others.
For my purpose I think just SSL/Https will do the job.
I just have no idea where to start. All the documentation I've read didn't help me...
Does anyone know a place where I can get some help or can anyone describe what to do to get this done ?
As far as I know I got to create a SelfSignedCertificate.
But where do I put it ?
Inside of my App(Resources)?
Please provide me some help.
Anything is highly appreciated.
EDIT 1:
As by now I have create a Custom Attribute EnforceSSL in my WebAPI.
All my WebRequests in my App are now HttpsWebRequests.
Does this mean all my traffic is secured ?
As far as I could find out in order to secure my API/Website I need a SSL-Certificate. I can either create one or buy one ... (is this correct) ?
I guess I need to inclued this in my IIS, where my API runs.
Do I need any Client Certificate which I have to install on the phones which use my app ?
I dont want this to go unanswered, in future for general security questions http://security.stackexchange.com is the place.
For my purpose I think just SSL/Https will do the job.
That's right use HTTPS (HTTP Secure). You can configure the webserver to redirect all http:// to https:// automatically. Follow this TechNet guide to Configuring Server Certificates in IIS 7.
I'd also recommend you test your web services out with https://www.ssllabs.com/ssltest/ that grades how secure your web site/service is. SSLLabs mainly catches TLS 1.1 vulnerabilities so make sure you're on the latest TLS to get a Grade A. TLS is basically the same thing as SSL. SSL 3.0 was the last version of SSL. TLS – Transport Layer Security, a new name for SSL. TLS 1.0 is colloquially considered “SSL 3.1”. Created and maintained by Internet Engineering Task Force. The latest version is TLS 1.2 and TLS 1.3 is currently in draft format.
All my WebRequests in my App are now HttpsWebRequests. Does this mean all my traffic is secured?
Nothing is 100% secure, but it sounds like you're following the recommended practices: https://developer.xamarin.com/guides/cross-platform/macios/http-stack/
Do I need any Client Certificate which I have to install on the phones which use my app?
What you're thinking of is called Certificate Pinning and https://forums.xamarin.com/discussion/8743/self-signed-cert-using-httpclient
The 3 most common mistakes to securing a mobile app are:
Hardcoding keys into source code:
Not using encryption correctly:
Not using HTTPS.
Securing Mobile Apps is such a large subject - there are entire books on the topic. At the very least read up on:
OWASP Mobile Security Project:
https://www.owasp.org/index.php/OWASP_Mobile_Security_Project and
Secure Coding Guidelines for iOS and Android: https://mgovlab.government.ae/uploads/SecureCodingGuidelines.pdf and make sure you've covered off the top 10 vulnerabilities:
Store local data securely
Protect remote data transportation
Implement appropriate authentication
Audit third-party code and services
Respect user data
Protect from reverse engineering
Secure web services and servers
Validate input and interprocess
communications
Avoid exploitable code errors
Distribute an application securely
When you package your application follow the offical Xamarin guide, pay attention to ProGuard.
https://developer.xamarin.com/guides/android/deployment,_testing,_and_metrics/publishing_an_application/part_1_-_preparing_an_application_for_release/
I have a Windows Service application written in C# which performs a number of tasks in the background. As a side-feature, the application offers interfaces for UI clients to connect to (currently a WPF client application). This is mainly WCF Data Services (OData) and WCF services for now, but may also include serving web pages (through embedding ASP.NET) so a browser could be used to access the service.
All of this works pretty well, with self-hosted services through ServiceHost+WSHttpBinding and DataServiceHost+WebHttpBinding, which is all setup in code (since it is somewhat dynamic/flexible).
Now I started to look into authentication and worked myself through setting up a basic authentication with a custom name/password validator through MessageCredentialType.UserName, UserNamePasswordValidationMode.Custom, etc. Now clients need to provide correct username/password which is validated against an application specific user list. This also works well, with something like
webHttpBinding = new WebHttpBinding(WebHttpSecurityMode.TransportCredentialOnly);
webHttpBinding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Basic;
serviceHost.Credentials.UserNameAuthentication.UserNamePasswordValidationMode = UserNamePasswordValidationMode.Custom;
serviceHost.Credentials.UserNameAuthentication.CustomUserNamePasswordValidator = new UserRepositoryPasswordValidator { UserRepository = UserRepository };
serviceHost.Authorization.PrincipalPermissionMode = PrincipalPermissionMode.Custom;
However, as I understand, without any kind of transport security, username/password as well as any data is being transmitted in plain text between client ans service, which is not desirable. I have therefore tried to find a way to use a secured/encrypted communication. This sounds like ssl/https would be the way to go.
I went through a number of articles to find out how to do this, but find the approach overly complicated and confusing. My application obviously does not use IIS or another web server, so many articles and posts do not seem to apply to my scenario.
Also, the application in question should be deployed/installed onto different target machines and "just run" without the need to tweak any operating system aspects. I was highly confused to see that using ssl/https requires to run netsh commands to register the certificate with the port, etc. Why is this so complicated?
I can accept that the certificate used for ssl/https would not be a highly trusted one, since it would be impractical to create a new certificate for every target machine my software gets installed on (most of which I do not even control or ever see).
Does anyone have instructions about a good acceptable strategy to get my current C# Windows Service with self-hosted WCF/WCF Data Services to use ssl/https without too much trouble and without complicating the installation process of my app?
J.-
Disclaimer: I've tried Googling for something that will do what I want, but no luck there. I'm hoping someone here might be able to lend a hand.
Background
I have a .NET class library that accesses a secure web service with the WSE 2.0 library. The web service provides a front-end to a central database (it's actually part of a data-sharing network spanning multiple customers) and the class library provides a simple wrapper around the web service calls to make it accessible from a legacy VB6 application. The legacy application uses the class library to retrieve and publish information to the web service. Currently, the application and class library DLL are both installed client-side on multiple workstations.
The Problem
The catch is that the web service we are accessing uses HTTPS and a valid X509 client certificate needs to be presented to the web service in order to access it. Since all of our components live on the client machine, this has led to deployment problems. For example, we have to download and install per-user certificates on each client machine, one for each user who might need to access the web service through our application. What's more, the web server itself must be accessed through a VPN (OpenVPN in particular), which means a VPN client has to be installed and configured on every client machine. It is a major pain (some of our customers have dozens of workstations).
The Proposed Solution
The proposed solution is to move all of this logic to a central server on the customer site. In this scenario, our legacy application would communicate with a local server, which will then go off and forward requests to the real web service. In addition, all of the X509 certificates would be installed on the server, instead of on each individual client computer, as part of the effort to simplify and centralize deployment.
So far, we've come up with three options:
Find a ready-made SOAP proxy server which can take incoming HTTP-based SOAP requests, modify the Host header and routing-related parts of the SOAP message (so they are pointing to the real web server), open an SSL connection to the real web server, present the correct client certificate to the server (based on a username-to-certificate mapping), forward the modified request, read the response, convert it back to plaintext, and send it back to the client.
Write a proxy server by hand that does everything I just mentioned.
Think of completely different and hopefully better way to solve this problem.
Rationale
The rationale for trying to find and/or write a SOAP proxy server is that our existing .NET wrapper library wouldn't have to be modified at all. We would simply point it at the proxy server instead of the real web service endpoint, using a plain HTTP connection instead of HTTPS. The proxy server will handle the request, modify it to so that the real web service will accept it (i.e. things like changing the SOAPAction header so that it is correct), handle the SSL/certificate handshake, and send the raw response data back to the client.
However, this sounds like an awful hack to me me at best. So, what our my options here?
Do I bite the bullet and write my own HTTP/SSL/SOAP/X509 aware proxy server to do all this?
Or...is there a ready-made solution with an extensible enough API that I can easily make it do what I want
Or...should I take a completely different approach?
The key issues we are trying to solve are (a) centralizing where certificates are stored to simplify installation and management of certificates and (b) setting things up so that the VPN connection to the web server only occurs from a single machine, instead of needing every client to have VPN client software installed.
Note we do not control the web server that is hosting the web service.
EDIT: To clarify, I have already implemented a (rather crappy) proxy server in C# that does meet the requirements, but something feels fundamentally wrong to me about this whole approach to the problem. So, ultimately, I am looking either for reassurance that I am on the right track, or helpful advice telling me I'm going about this the completely wrong way, and any tips for doing it a better way (if there is one, which I suspect there is).
Apache Camel would fit the bill perfectly. Camel is a lightweight framework for doing exactly this kind of application integration. I've used it to do some similar http proxying in the past.
Camel uses a very expressive DSL for defining routes between endpoint. In your case you want to stand up a server that is visible to all the client machines at your customer site and whatever requests it receives you want to route 'from' this endpoint 'to' your secure endpoint via https.
You'll need to create a simple class that defines the route. It should extend RouteBuilder and override the configure method
public class WebServiceProxy extends RouteBuilder
{
public void configure()
{
from("jetty:http://0.0.0.0:8080/myServicePath")
.to("https://mysecureserver/myServicePath");
}
}
Add this to a Camel context and you'll be good to go.
CamelContext context = new DefaultCamelContext();
context.addRoute(new WebServiceProxy());
context.start();
This route will create a webserver using jetty bound to 8080 on all local interfaces. Any requests sent to /myServicePath will get routed directly to your webservice defined by the uri https://mysecureserver/myServicePath. You define the endpoints using simple uris and the dsl and camel takes care of the heavy lifting.
You may need to configure a keystore with your certs in in and make it available to the http component. Post again if you've trouble here ;)
I'd read the camel docs for the http component for more details, check the unit tests for the project too as they are chock full of examples and best practices.
HTH.
FYI: To have the http component use your keystore, you'll need to set the following properties
System.setProperty("javax.net.ssl.trustStore", "path/to/keystore");
System.setProperty("javax.net.ssl.trustStorePassword", "keystore-password");
You should look into WCF, which supports the WS-Addressing protocol. I believe I've seen articles (in MSDN, I think) on writing routers using WCF.
You should also get rid of WSE 2.0 as soon as possible. It's very badly obsolete (having been replaced by WSE 3.0, which is also obsolete). All of its functions have been superceded by WCF.
I believe an ESB (Enterprise Service Bus) could be a viable, robust solution to your problem. There is an open source ESB called Mule, which I've never used. I did mess around with ALSB (AquaLogic Service Bus) a while back, but it would be expensive for what you are describing. Anyway, the thing that you would want to look at in particular is the routing. I'm not sure it would be a simple plug 'n play, but it is indeed another option.
You can also do this with Microsoft ISA Server, a commercial Proxy/Cache server. It will do many of the things you need out of the box. For anything that is not possible out of the box, you can write an extension to the server to get it done.
ISA Server is not free.
ISA is now being renamed to "Microsoft Forefront Threat Management Gateway".
It is much more than a web proxy server, though - it has support for many protocols and
lots of features. Maybe more than you need.
There is a service virtualization tool from Microsoft available on Codeplex called the Managed Service Engine which is intended to decouple the client from the web service implementation. It might fill the bill or give you a running start. I haven't really investigated it thoroughly, just skimmed an article in MSDN and your description reminded me of it.
http://www.codeplex.com/servicesengine
http://msdn.microsoft.com/en-us/magazine/dd727511.aspx
Your security model doesn't make sense to me. What is the purpose of using HTTPS? Usually it is to authenticate the service to the clients. In that case, why does the server need to keep the clients' certificates? It is the clients who should be keeping the server's X509 Certificate.
Why do you need to go through VPN? If you need to authenticate clients, there are better ways to do that. You can either enable mutual authentication in SSL, or use XML-Security and possibly WS-Security to secure the service at the SOAP level. Even if you do use SSL to authenticate clients, you still shouldn't keep all the client certificates on the server, but rather use PKI and verify the client certificates to a trusted root.
Finally, specifically for your proposed proxy-based solution, I don't see why you need anything SOAP-specific. Don't you just need a web server that can forward any HTTP request to a remote HTTPS server? I don't know how to do this offhand, but I'd be investigating the likes of Apache and IIS...