Hi André, The endpoint is an internal service with published WSDL/XSDs. The 3rd party client app used JAX-WS to invoke on it. Overriding client to use an in-house URL protocol handler could be an option for solving the HTTPS/MA issue. But if we introduce a WS policy to sign and encrypt the messages as well then it becomes more complex again. My point here is that standing back from the problem at hand and taking a broader architecture/security perspective raises other challenges.
I think the right thing to do is a feature request on the 3rd party or write a client library that does these things which the client app could invoke on instead of using JAX-WS. Well it was worth exploring this and I learned a huge amount, so my thanks again for your continuing interest and advice. Diarmuid On 9 Jan 2015 16:44, "André Warnier" <a...@ice-sa.com> wrote: > Christopher Schultz wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> Chuck, >> >> On 1/8/15 6:21 PM, Caldarale, Charles R wrote: >> >>> From: dmccrthy [mailto:dmccr...@gmail.com] Subject: Re: Tomcat >>>> 7.0.56 - How to configure Tomcat/JRE 7u72 for client HTTPS Mutual >>>> Authentication connections >>>> I found the link below from 2008. It looks like a minor change to >>>> the Catalina WebAppLoader class might solve the problem and let >>>> me provide a custom HTTPS URL protocol handler. Have I misread >>>> this? >>>> http://tomcat.10.x6.nabble.com/Custom-URL-handlers-in- >>>> Tomcat-web-app-td2006418.html >>>> >>> This is for requests coming _into_ Tomcat, not any outbound >>> requests your webapp is doing - which Tomcat is not involved in (or >>> even aware of) at all. Again, you need some sort of proxy, if your >>> webapp cannot be changed to do the right thing. >>> >> >> No, this is for constructing URLs and using classes like URLConnection >> to access them. If the underlying code (e.g. Apache httpclient) uses >> URLConnection under the hood, then this technique will work. >> >> This is actually what my initial suggestion was in my first reply to >> this thread: install a stream handler for a particular protocol. >> >> The thing is, I don't think you'd want to do this for *all* http:// >> URLs... only those that should be converted into secure ones. So you'd >> have to be able to change the URL. >> >> Another thought: use stunnel. It's probably the simplest possible >> thing to set up. Have stunnel listen on a nearby host (perhaps >> localhost) for non-secure HTTP connections, and connect the other end >> to the "real" server's HTTPS port. We do this at $work to deal with a >> product that doesn't support HTTPS internally, just as the OP is doing. >> >> > I think that the final answer is : "it depends". > I've done a few of these "proxy hacks" in the past, for various purposes, > including a couple of failed attempts too (but rich in lessons). > If you know exactly what kind of requests the client (the webapp in this > case) is sending to what server, and you know exactly what it gets in > response, then you can usually do something of the "man in the middle" kind > of thing. > But by experience, some websites return really nightmarish stuff, full of > re-directs, javascript modules making their own connections elsewhere, > cookies containing information needed to access follow-up pages and > whatnot, and that can quickly become unmanageable. > (Think Akamai, ads and analytics sites, www.bbc.com and img.bbc.com, > balancing proxies etc..) > > I have a couple of questions here, for my own edification but I believe > also on-topic for the OP : > > We have this webapp making a HTTP connection on the side, to some > third-party host. > It is a fair bet that the creators of that webapp did not start from > scratch, and that they used some existing library to do that (à la > httpclient as Chris suggested). > > First question thus : even not having the source code of the webapp, can > one easily find out what it uses in order to make that HTTP connection ? > > Assuming that the answer to the previous question is yes, second question : > If a webapp "invokes" a given class to create such a connection, where > does java look first for the corresponding class ? in the webapp's own > WEB-INF/classes or WEB-INF/lib ? > > And if the answer to that is also yes, can one place a jar there, with > classes having the same name as the one which the webapp would normally > invoke, and which would be found first/override the usual ones it uses ? > > And could such a class examine the original request URL, and if it is not > one that it should intercept and massage, just delegate the call to the > similarly-named "normal" class ? > > Or is there something fundamentally uncouth/illegal/fattening in such a > scheme ? > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
