[Apologies that this is not threaded with the original post]
> Following on from the issue of certificate management, is the issue of
> authentication. This hasn't been an issue thus far, because Xen has zero
> authentication. I'm not planning to make this same mistake with the QEMU
> management daemon though - its going to have a secure data transport and
> real authentication from day-1. Thus we need to consider how
authentication
> is exposed at the libvirt client API layer.
>
> First off, there are many possible authentication approaches:
>
> - Username + password
> - Username + one time key
> - Username + password digest
> - Kerberos tickets
> - x509 certificates
> - ...etc
I would definitely avoid over-engineering a solution.
I suspect that "large corp" users will understand certificate
infrastructures -- they probably already use X.509 client certificates
to authenticate desktops -- and will be able to manage those. Everyone
else will want to use ssh, the model for that being the way cvs allows
you to flexibly hand over authentication problems to an external program
through setting the $CVS_RSH environment variable.
It's so easy to set up ssh to get passwordless remote logins. If they
haven't set that up, and they're using libvirt through a command line
tool like virsh then they'll get a prompt from ssh to type a password.
ssh also has the advantage that it is very widely installed.
The only issue is what command to run on the remote system. A simple
command line tool which talks to the daemon over a socket might be one
option. nc (netcat), gnutls_cli or stunnel might work too.
Rich.
--
Red Hat UK Ltd.
64 Baker Street, London, W1U 7DF
Mobile: +44 7866 314 421 (will change soon)