Not completely sure which section to ask this question in, thought I'd try the tomcat section first!
I have a reasonably complex web application deployed and running in tomcat. The application is designed to handle multiple customers/sites, so instead of deploying the single application at each customer/site I would like to keep a single install (plus database) under my control. This has advantages in terms of support, upgrades, backups, monitoring, etc ..
If a customer is no longer going to get the actual application, they will need some kind of proxy application. They can't just access the application I host directly as some customers need input from their own environment, e.g. authentication via internal LDAP server. I need to decide on an implementation that allows the following.
* Allow a customer to visit http://internal-ip.com/myapp/listCourses.do and have the proxy transparently return a web page from http://external-ip.com/myapp/listCourses.do * Allow the proxy to authenticate the users locally (via internal LDAP server)
* Allow the proxy to cache and serve some content locally, e.g. a large video file would be downloaded once, then served from the proxy.
* Allow the web application structure to change (move pages) without having to update the proxy application, e.g. no hardcoded URL mappings on the proxy. Proxy is as generic as possible and would be able to proxy any web application.
My initial ideas for implementation involve writing a web application, deployed in tomcat/jetty. When a HTTP request comes in, its path is examined to check if a local action is required (e.g. authentication). If not, use a package like Apache HttpClient to make a request to the server run by me. What I don't really like about this implementation is the manual cookie management between the proxy server and the server I run, but I'm not sure how to avoid it.
Alternatively, a java proxy server is hardly a new concept. I don't have much experience with open source java proxies that I could utilise/modify to achieve this. Any pointers to software others have experience with, gratefully received
CUSTOMER -------> PROXY SERVER --------> REMOTE SERVER
Interesting problem. And one complex enough I'm probably missing some of the better parts.
I think you're probably setting yourself up for trouble if you try and "front" the security like that. It sounds like putting something fairly complex on the client's side that aside from everything else is likely to get out of sync with the current version of the system on your cloud server. In other words, much the same problem as you have now, but more arcane components, so making sense of problems would be that much more difficult.
You'd probably do much better if you could define a security service on the client side that the cloud server could invoke at need. This might be a web service invoked by a Tomcat Realm module, for example.
Of course, to do something like that, you'd need to have the ability for the cloud server to be able to call the client. If that's not possible, your next best bet would probably be to install a proxy server such as Apache or Squid that could "piggyback" the credentials on a request. That's likely to be harder to maintain and probably less secure, however.
I don't think it's likely to be worth the expense and trouble to write your own client-side proxy.
"privilege" comes from the Latin words for "private" and "law" (legal) and dates to feudal times. To "claim privilege" meant that you were above the laws that applied to the common people.
posted 10 years ago
Tim Holloway wrote:I don't think it's likely to be worth the expense and trouble to write your own client-side proxy.
The plan is that this would be an extra software component and completely separate from the main application. It would only be created if time/budget permitted.
It'd be naive to think this proxy would never need updating, so a customer would still actually need to perform a software update. This would be very simple though, considering there is no DB associated with it. I'm a little undecided on the acceptability, but I have already created a framework that would allow automated updates (assuming an internet connection) without intervention from the customer.
Since using webex style remoting tools, customer support has become easier, but not all customers are keen on it. It'd be a big plus to have 90% of the changes made on a local server than trying to guide a customer through doing it on their setup.
In summary, I still like the idea - who wouldn't, it's technically quite cool I'll dig into a true java proxy server (like OWASP proxy) and see how much of the code I can make use of. I may have a fiddle doing it manually with HttpClient as well, although this is all going to be reconnaissance at the moment - the project may get rejected when I report an estimated cost with too may 0's on it!
We've gotta get close enough to that helmet to pull the choke on it's engine and flood his mind! Or, we could just read this tiny ad: