Sorry if the question is asked before. I searched but i can't find a way to solve my problem.
I have a web api (i don't use owin or something like that). The api creates task from data with sent by application and returns the taskId and pageId to application to pass it as get/post parameter to website. After that, The application that integrate the web api, redirect to one of my web application's page to complete the task created by my web api. I have some security flows such as appid-password to control accessed application. But this has some security problem.
If a customer share the appid and password with another person, then appid password info could use by a disallowed application.
Here is what i tried to solve the problem,
I tried to get HttpContext.Current.Request.Headers["Origin"] info but the application that entegrate my web api must send the header and it could not solve the problem. Because same "Origin" header can be sent by bunch of applications. I try to use the HttpContext.Current.Request.Headers["REMOTE_ADDR"] or HttpContext.Current.Request.Headers["REMOTE_HOST"] and both of returns the IP address of customer's application's IP Address. And these are could'not solve my problem too. Because in one server there may be thousands of applications. I tried to solve the Dns from an IP address but i could not achieve this because the entegrated application may not registered or it can't be accessible by outside network.
What is the best way to solve this problem? Thanks for helps.
I have a self-hosted WCF service, which is available from all computers of the company. This has a standard landing page ("You have created a service. To test this service..."). I want to make sure that this landing page and the WSDL links on it are only accessible from the local server, as the information contained there could potentially be a security risk.
What is the easiest way to make sure that any URL that is not tied to a service is only accessible from localhost?
Please note that I do not want to change the contents of the landing page, as the WSDL links are useful for developers.
I am interested in solutions that involve modifying the app.config or limiting access via code.
As far as I know you can't selectively grant access to WSDL/Test WCF pages only by config or code. You can disabled it or not.
You could implement some sort of rules at IIS level to prevent access from non local addresses, but would make the question more suitable for Super Admin, probably.
If WSDL and/or service description pages public are secutiry issue, though, maybe you need to rethink your services security. Methods should be secured by authentication/authorization of some sort (usually via tokens). If anyone can post to your method and run code without proper authorization, having the interface description public is the last of your problems.
PS: if needed for devs, you can generate static versions of WSDLs to be served from user/password protected path.
I have coded a C# MVC5 Internet application and I have a Web API 2 web service that returns JSON data. I am retrieving this JSON data in an android application.
How can I add a feature to the web service such that only my android application can retrieve the JSON data? I am wanting to do this so that other web users cannot hammer the url and the web service will not send my data to unwanted applications and/or users.
Is this possible? If so, how should I do this?
Thanks in advance.
You have various ways to achieve this in fact.
For example, you can store a key in your android application and use send this key together with the request to your WebAPI. Your webAPI will than check if they key is valid and if it is, it will return the JSon.
However, there's no way to ensure that nobody else can request and get your data. For example by reverse engineering your android application and extracting the key, or by monitoring the network traffic and find the key in there.
You need to understand that there isn't anthing that guarantuees you 100% security.
See it as the following:
You have an open door right now, you can close it little by little, but closing and locking down is not possible. There will always be gap. A house also can't by made burglar proof, but you can make it very hard for a buglar to enter.
Go to this link Web Api. I have used the individual authentication for my web api. When you will register the user the response you will get is access token and use that access token as Authentication header in your ajax call if you are using Jquery ajax to call your Web Api. Refer this The OAuth 2.0 Authorization Framework. Hope this help you.
Are you looking for something like this?
http://httpd.apache.org/docs/2.2/howto/access.html
If you have other web server, there should be appropriate means to support such.
I have a challenge and I believe there is a developer smarter than me that can provide some insight.
I have a web service. This web service is written with ASP.NET MVC in C#. I want to allow developers to call this web service. When developers are writing code, I recognize that web apps typically run from localhost. When they call this service, I want to be able to identify if the request is coming from localhost. However, if I look at the IP address, its the IP address of their machine.
Is there a way for me to even do this? Clearly Request.IsLocal won't work as my web service is running on an entirely different machine.
When you call a web service, the browser usually passes the page in the Referer header. So you can check if that value starts with "http://localhost". Virtually anything in an http request can be forged (including this), so be careful what kind of decisions you make based on this data.
Without passing some additional data along with the request from the app, there's not going to be any way for you to know.
You'll only be able to get the IP address or Host name that was used to make the request to your Web Service and it sounds like you want to be able to find the Host Name (localhost) that was used to make the request to the app (which then triggers the call to the Web Service).
How will you then define local (from the perspective of your service)? You'd be better off setting up a development service on a different API end point instead of attempting to guess this.
All production level API calls can go to something like api.yourservice.com with all development level requests coming in via dev.yourservice.com.
You can then have two separate services or have your service read the URL being requested and differentiate based on this.
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...