The title of the JIRA case says it all. *Some* authentication between live/backup is desired.

As we envision that some 'spare' backup servers will be going round trying to assume the part of replicating backup of several different live servers, it does not make sense to have a single password set somewhere.

My initial idea for implementing this is to add a password field to the TransportConfiguration API. As it would allow a somewhat transparent way of (optionally) adding a password for a given connection specification.

A primary issue with it is that TransportConfigurations are also resent left and right to, for instance, notifying of ClusterTopology changes. So to avoid brodcasting the password with the T.C., I propose removing it from the TransportConfiguration copies that are returned from Configuration, and use some new method getT.C.WithPasswords() (or any more sensible name) to access instances with the passwords.

Any opinions / alternatives?