I'm intending to use XMLRPC over a SSL connection which is configured to
use both server and client authentication. In addition, I will be
embedding the XMLRPC client inside an application that is already using
SSL itself (Tomcat).
This has two consequences.
1. I need to use specific trust and key stores for the XMLRPC library.
That means I can't use the approach suggested in the XMLRPC FAQ of
setting the HttpsURLConnection default socket factory, as I can't assume
I can set the trust and key managers globally.
2. I need to be sure that any client SSL sockets that are created by the
XMLRPC library have the needClientAuth flag turned on.
It's proving *incredibly* difficult to do this, both because of problems
in the J2EE SSL classes (which I'm raising internally), and because of
problems in the Apache XMLRPC library. I've managed to work around
issue #1 by subclassing ServletWebServer and overriding
createServerSocket, but I'm stuck with issue #2. My preference is to
use the XmlRpcSunHttpTransport mechanism, but I can's see any way of
turning on needClientAuth with that. XmlRpcCommonsTransport also
doesn't seem to have any way of doing this. XmlRpcLiteHttpTransport on
the other hand *does* have a newSocket method I could override, but as
far as I can make out from
http://issues.apache.org/jira/browse/XMLRPC-101, XmlRpcLiteHttpTransport
doesn't support SSL.
XMLRPC-101 looks like it would do what I need, but it also looks like it
is stuck in the pipeline waiting for 3.0 to be released - is there any
sort of an ETA for this fix?
I've also noticed the thread in the archives about Apache XMLRPC
becoming dormant as a project. Is this really the case? The only other
alternative to the Apache library seems to be the Redstone one, and that
looked to me like it wouldn't support what I wanted to do at all.
--
Alan Burlison
--
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
