All DJ peer-to-peer communication should be secured using mutual TLS (mTLS) and system accounts where possible.
- replication protocol: DS-RS and RS-RS
- proxy: for discovery and proxying requests
- crypto-manager: using "get symmetric key" request for distributing symmetric keys.
The goal is to prevent using a login/password to authenticate during machine to machine communications.
This story needs
OPENDJ-5866 to be resolved since it relies on the new deployment model (deployment key and CA cert).
It also depends on
OPENDJ-4702 in order to be able to configure the proxy to use SASL External authentication in configuration.
This issue could be closed once:
- The setup tool will create a "service account" in a single entry backend containing attributes similar to the one below:
- ds-proxy-profile will configure the replication discovery mechanism to use SASL External in order to bind to the backend servers with the cn=service account
Below are former acceptance criteria from
OPENDJ-5866 description from which this story has been moved:
Note: we should have stronger validation of the CA cert, see
and OPENDJ-4716. OPENDJ-4712
To be confirmed: should the account entry a) be mutable, nor b) replicated? Only if we want to maintain password policy state and support lockout, but I'm not sure we do.
The SASL mechanism default configuration should refer to an additional "Subject DN to User Attribute" which maps to system accounts in private backends
Regarding b), as discussed with Matt, the service account should not have to be replicated, at least in a first time.