Project

General

Profile

Actions

Bug #414

closed

public key server for referral LDAP servers

Added by Matt Jones about 22 years ago. Updated about 16 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
metacat
Target version:
Start date:
02/07/2002
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
414

Description

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?

Actions #1

Updated by Jing Tao about 22 years ago

We can add a flag - installedPublicKey to LDAP server. If theflag is true, this means its public key already was installed and we don'tneed install it again. If it is false, we can retrieve and install it.

Actions #2

Updated by Matt Jones about 22 years ago

Moved issues that we do not intend to address during the current release to the
'Postpone' milestone.

Actions #3

Updated by Jing Tao about 16 years ago

It is done by sid. We can use both secure and plaint way to access referral LDAP servers

Actions #4

Updated by Redmine Admin almost 11 years ago

Original Bugzilla ID was 414

Actions

Also available in: Atom PDF