Daniel Noll wrote:
I'll never stop wondering why people are using this stuff for serious
jobs.
(a) Because it is there.
(b) Because they have no need for a full web server as their XML-RPC
service is the only thing on the entire server.
In our case it's a little more complex: We are running the Apache
XML-RPC server embedded inside Tomcat. Tomcat is providing a HTTPS web
service on port 443, and the XML-RPC service is also running over SSL on
port 1443.
The HTTPS service uses a normal server cert, the XML-RPC service uses a
different set of certs issued by a private CA, and does both client and
server cert validation so we can secure the XML-RPC interface and only
permit specific client applications to connect to it.
Although you can configure Tomcat to do client cert validation, you
can't configure it to use different sets of certs for different ports -
or at least I haven't been able to find how to do it.
We have custom socket factories that we use for the XML-RPC service that
use the XML-RPC service certs, and we use the web server class that
comes with XML-RPC web so that we can control how the sockets are
created, and thereby make sure they use the cert store containing the
private certs.
We could probably write our own plugin for Tomcat that did the same, but
that would be more complicated, and then we would be tied to a
particular servlet container. Using the Apache XML-RPC webserver class
was the simplest option.
--
Alan Burlison
--
