WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-api

[Xen-API] Use of PAM for authentication & SSL comms

To: xen-api@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-API] Use of PAM for authentication & SSL comms
From: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Date: Tue, 31 Oct 2006 23:29:52 +0000
Delivery-date: Thu, 02 Nov 2006 13:44:11 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-api-request@lists.xensource.com?subject=help>
List-id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com>
List-post: <mailto:xen-api@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=unsubscribe>
Reply-to: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Sender: xen-api-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.1i
I'm not had much time to actually try the new Xen-API work yet, so have
merely been reading the commits as the come in to keep track of work.
I wanted to raise the question of authentication. Changeset 77 in
the xen-api.hg branch switched Xen-API over to use PAM for authentication
of the remote logins.

  http://xenbits.xensource.com/ext/xen-api.hg?cs=9bad549c20e3

This is very nice in principle, but I've a couple of thoughts about
the particular impl.

 - The XML-RPC api is using a login method where you explicitly
   pass in a username & password as the two params. This doesn't
   really match up with the PAM model of conversation functions
   which request one or more pieces of auth info in sequence. It
   strikes me that since XML-RPC is a bi-directional protocol it
   would make alot more sense to allow the PAM conversation callbacks
   to go back & forth over the XML-RPC channel to collect data from
   the client as needed, rather than having the client provide 
   the username & password ahead of time.

   By removing the fixed user/passwd at the client end of the API
   it'll be possible to add in support for all the different types
   of auth people can configure with PAM. The obvious one being
   kerberos GSSAPI single sign on.

 - XenD should install its own PAM config file into /etc/pam.d
   rather than re-using the context from the 'login' program

 - If we're using PAM then we must switch all communications to use
   SSL by default - no network daemon should be using system
   passwords over a cleartext network channel anymore. If we want
   to keep a cleartext channel, then we should use a separate 
   password database & certainly not system logins

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  -=| 

_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

<Prev in Thread] Current Thread [Next in Thread>