I've to develop a WPF application in an intranet environment with no internet access for security reason. I was wondering if it's possible to collect data locally (on a server) then to FTP them or even better to have the application insight alternative installed on a Server.
Has anyone faced a similar situation and have been able to solve it?
You could do something like that yourself if you really needed to. Instead of using the built in InMemoryChannel or ServerChannel classes to send telemetry, you'd create your own implementation to store them somewhere else. (or you could change the endpoint that the default channels point to to a web service inside the intranet.
you could then collect those files up and ftp them outside, and write another service to read those files and send the telemetry to app insights. Though it seems less like a good idea given the intranet with no internet for security reasons.
Or, better yet, you could simply write internal service to parse and store all that telemetry and show it on that web service inside the intranet and use appinsights only as an sdk and schema, and don't send any of your data outside your intranet at all.
More likely: upvote adding AI to azure stack, (https://feedback.azure.com/forums/357324-application-insights/suggestions/11683746-bring-application-insights-to-azure-stack) and then get an azure stack implementation inside your intranet? then you get all the other goodies of Azure from Azure stack as well.
This seems like a duplicate question - but after hours of search, it seems there is no clear question-answer which summarize the issues i'm raising here.
We have a web application (built using asp.net MVC4) which stores customers sensitive customer information.
We've decided to migrate our entire application to https.
My question is, except for the IIS and certificates technical issues, which we've already know how to deal with, what should be changed on code level?
What will happen for instance for:
Included external scripts containing http, such as: http://code.jquery.com/jquery-1.7.1.min.js - will it work automatically without any problem and popup messages or blocking on the client browsers?
Internal links, which we've forgotten to change, which redirect to our site using http?
Images/Sources which have http in their URL.
Should we change all references from http to relative, or just specifying // without the http/https protocol ? (as seen on other posts on this subject)
Should we do nothing, will it happen automatically?
Is there a way to do something in IIS or Global.asax etc, in order to automatically take care of all http leftovers?
What else should we take in account when migrating to https?
Thanks in advance.
For all internal static resources hopefully you have used #Url.Content helper and for all internal dynamic resources you have used #Html.ActionLink, #Html.BeginForm, ... helpers to generate the links. This way you don't need to worry about anything.
For all external resources you could use // syntax in the link which will respect the protocol.
Since you are switching to HTTPS you might consider marking all your cookies (if any) with the secure flag to ensure that they are transmitted only over a secure channel.
Something that seems to be absent from the otherwise great new features for Windows Azure (announced on June 7th), is the ability to define distributed caches for the reserved instances of a Website Cluster in Reserved Instance Mode.
As of now it seems to be only possible to create distributed caches for standalone webroles or worker roles. Does anyone know a workaround or know if this is something that is coming?
The reason why I'm asking this is because it forces me to create a dedicated worker role for caching and since I'm contrained by costs I can't afford another three instances just for caching. This leaves me with a caching service that's not fault tolerant when in reality my three Webroles hosting the Websites would be a) fault tolerant and b) could contribute enough memory to the distributed cache that I'd gain a much larger cache without a single point of failure as with a single caching workerrole.
This scenario is not supported as of today by Windows Azure Caching (Preview). Thanks for the feedback. I will take this up to the appropriate folks in our team to consider the same for future releases.
As mentioned by Jason and Win, for now you can use Windows Azure Shared Caching. Though you are right that it is limited in Size and has a quota system.
Previously known as the app fabric cache, I think this does what you want?
http://msdn.microsoft.com/en-us/library/windowsazure/hh914133.aspx
http://msdn.microsoft.com/en-us/magazine/gg983488.aspx
You sure can create Dedicated Cache for windows Azure websites in reserved mode. As of now you may not be able to find how to create it in Windows Azure June SDK (1.7) however if really want to do it you need to accomplish it manually.
I had some discussion around this and after some digging I found that it can be done by understanding the dedicated cache in Windows Azure Web Role first and the migrating the references & configuration to your ASP.NET Website. Here are some steps you can follow to try it by yourself:
Create a Web Role with dedicate cache
Understand the references and configuration settings used for Dedicated Cache in web role
Now create your ASP.NET Website and migrate dedicated cache related settings and references to your Windows Azure website
I have the following situation (.NET, C#):
My web service needs authentication data, which is stored in a database. The authentication is used for large volume POSTs done to the web service with transactional data. However, it is too heavy for to query the database every time there is a POST, because we are talking many transactions per second. I therefore want to keep the variables for authentication in Cache - which I can do via AppSettings. How do I load these variables into AppSettings when the web services is first started, without some manual process I need to remember to do?
Thanks,
Anders
It's not so easy to save information to web.config or app.config into AppSettings. Truly speaking, for me it's look dangerous when service tries to modify web.config, because a tiny error could cause all service to go down.
Anyway, when you need it, here is link for MSDN article, use ConfigurationManager class. And this article has a full example how to do it:
http://msdn.microsoft.com/en-us/library/system.configuration.configurationmanager.aspx
But I suggest you another approach. Use caching either simple System.Runtime.Caching.MemoryCache (or System.Web.Caching.Cache as in one of comments said) or more advanced and scalable scenario using AppFabric caching (for exampe have found link on stackoverflow for you)
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...