Bug #502
closedSecurity issues in replication
0%
Description
During the replication, security is a issue too. At least, we need some
authentication for control server list.
We maybe set a table name xml_replicationadmin in database and store some
administrative users and their password there. So we can check the
authentication for it.
Updated by Jing Tao over 22 years ago
public key couldn't control the replication.
If in NCEAS keystore, it didn't contaion LTER's public key. But LTER is still
in the replication table in NCEAS. NCEAS couldn't replicate a document to LTER
by Force Replication because untrust chain. This is good.
But, LTER can used delt T replication to get the doucments from NCEAS easily (
LTER is easy to install NCEAS public key in its keystore).
So the installation of public key in key store can control Force replication,
but couldn't control delt T replciation.
Updated by Jing Tao over 22 years ago
Now code was changed and public key can be a control for replcation. Even a
server is the replication server list, but if its public key is NOT in the
metacat default keystore, replciation couldn't be carried out by either force
or delta T replication.
A very simple action "test" was added into MetacatReplication class. It only
send back a successful message.
In handleUpdateRequest, handlGetDocumentRequest and handleGetDataFileRequest,
the test action will be executed by sending request through "https" at first.
So if LTER send a getDocument request to NCEAS, NCEAS should send back a test
action to LTER by https. If public key of LTER was not installed in the
default keystore in NCEAS, this will cause a exception. So NCEAS would not
send the document to LTER. If LTER's public key was installed, the document
will be sent. Same thing will happen to handleUpdateRequest and
handlGetDataFileRequest too.
The installation of public key into keystore will control the replicaion
happend or not. So it becomes an authentication for replication. Administrator
of MetaCat can control it.