Peoples,
Question to all - is there any interest in building up the following
within the ASF? Maybe as a sub-project of the security project we have
been discussing?
As part of the implementation of the XKMS messaging, I have built a
prototype XKMS server. It's very rough, but quite modular. The idea
being that you can plug different handlers in to deal with different
types of XKMS (or other) requests. Currently I've only implemented a DB
XKMS handler for interop testing - it reads and writes keys into a MySQL
database. But I'm about to do an LDAP based XKISS module so that you
can retrieve certs/keys from a LDAP repository.
The end idea is that you can mix and match the modules to do what you
need to do. So as a further example, a LocateRequest could be satisfied
by an LDAP handler module, a ValidateRequest from an OCSP handler module
and a RegisterRequest from a SCEP based module. Of course this is all
for a PKI based backend - the DB module could be enhanced for native
XKMS handling.
The core transaction handler is built from the APR libraries, and I have
it running under both Linux and Windows. But the thread and incoming
request processing is still quite naive. The main handler is C, and
then goes to C++ when you actually parse the XML coming in and hand to
the appropriate module. There is an apache mod (mod_txhd) that runs
under a Apache 1.2 server to pass transactions coming in to the actual
daemon service.
The core handler also implements a pipeline approach. So an incoming
(for example) SOAP 11 wrapped LocateRequest message gets processed by a
bunch of isolated handlers ->
1. Parse
2. Strip SOAP 1.1 envelope
3. XKMS DB based retrieve of key
4. Wrap response in SOAP 1.1 envelope
5. Serialise
The handlers are configured via an xml file, so you can use the same
xkms db module to process soap and non-soap based requests, and the db
handler doesn't care.
I haven't really documented much around it yet. But you can see the
interop service I built at www.wingsofhermes.org/xkms
Cheers,
Berin
