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 So of these require prompting the user for data (eg username / password), others will pick up their credentials from known sources (eg, the keberos ticket cache file in /tmp/krbXXX), or have to be provided ahead of time as part of the transport layer securit protocol (eg the x509 certificate file). We don't have to consider the latter case, since that's taken care of by the certificate management API - unless we want to figure out a more unified API, but I'm not sure it would be particularly sane. The interesting case from an API point of view is the first, which requires prompting the user for data. This is pretty much the PAM approach, with the added complication that you're in the middle of a network protocol and you may have several wire messages going back & forth, each time requesting more pieces of info. ie you can't possibly gather the neccessary info ahead of time. So we need some form of callback to collect the neccessary auth data. The network protocol equivalent of PAM is SASL. This actually has a number of different types of callback function yuou can register, depending on what sort of data you're prepared to provide as a client - Challenge / response: - const char *challenge - const char *prompt - const char *defresult, - const char **result, - unsigned *len - Password, username, language - const char **result - unsigned *len - AUthentication realm - const char **availrealms, - const char **result There are a few more auth callback types defined in SASL spec, which I've omitted here for brevity. We could map this onto an API something like this: enum { VIR_CONN_AUTH_PASSWORD, VIR_CONN_AUTH_USERNAME, VIR_CONN_AUTH_LANG, VIR_CONN_AUTH_CHALLENGE, VIR_CONN_AUTH_REALM, } virConnectAuthToken; typedef int (virConnectAuthCBSimple)(const char **result, unsigned *len); typedef int (virConnectAuthCBPrompt)(const char *challenge, const char *prompt, const char *defresult, const char *result, unsigned *len); typedef int (virConnetAuthCBRealm)(const char **availrealms, const char *result); typedef struct { int token; union { virConnectAuthCBSimple simple; virConnectAuthCBPrompt prompt; virConnectAuthCBRealm realm; } cb; } virConnectAuthCallback; int virConnectSetAuthCallbacks(virConnectAuthCallback *cbs, int ncbs); Now, of course not everything is going to be SASL based - Xen may well end up using TLS/SSL + HTTP Basic auth. There's a couple of other HTTP related auth protocols too. They are all basically a subset of SASL provides, so the above API ought to be sufficient to serve their auth needs too. Finally, one could simply say, this is all rather complicated, why don't we just use a simple username+password for everything. While this would be nice from a coding POV, I think we need to be forward looking and ensure we're setup to cope with things like Kerberos single-sign-on. This is why I'm looking at SASL for the QEMU authentication process - if you use libsasl.so you're app doesn't even need to know what auth method it is using - the admin can simple create an appropriate config file for sasl, and bingo you're fully kerberized & single sign-on capable. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|