Metacat

Right now, all metacat servers point at ldap.ecoinformatics.org for
authentication. When we turn on SSL, those servers will need to to be
configured with the public key from ldap.ecoinformatics.org in order to
communicate securely. Sometimes the response will be a referral to another ldap
server. To continue the secure communication, metacat will need the public key
from the referral server too. This will become problematics as the number of
ldap servers grows and the number of metacat servers grows, because every
metacat in the network will need the public key from every ldap server. Also,
every metacat server would need to add the public key of any ldap server added
to the network later. This is clearly unworkable over the long run.

Proposed solution: have all referral ldap servers have two entries in
ldap.ecoinformatics.org. One entry contains the referral (as now), the other
contains the public key for the referral server. When a metacat server is
passed a referral from ldap.ecoinformatics.org, it can also retrieve and install
the public key for that server, and thus set up a secure communications channel
with the referred server. This mechanism means that each metacat that is set up
will need to be set up with a single ldap server public key, and the rest will
be obtained automatically.

Oc course, this requires code changes in metacat's referral handling. Under
this scenario, when metacat gets a referral, it must send another LDAP query to
get the public key for the referral server, install it (using the java commands
that are equivalent to 'keytool'), and then it can continue with its
communication request to the referred ldap server.

The root ldap server is a major source of single-point failures, so we're going
to want to replicate the root server functionality. This might require a
slightly more complicated installation, but ultimately would be more
fault-tolerant. This should be implemented in a second step, after the
single-point procedure is worked out and functional.

Comments?