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

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

To: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Subject: Re: [Xen-API] Use of PAM for authentication & SSL comms
From: Alastair Tse <atse@xxxxxxxxxxxxx>
Date: Wed, 1 Nov 2006 11:38:47 +0000
Cc: xen-api@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 02 Nov 2006 13:43:56 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20061031232952.GB30970@xxxxxxxxxx>
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>
References: <20061031232952.GB30970@xxxxxxxxxx>
Sender: xen-api-bounces@xxxxxxxxxxxxxxxxxxx

On 31 Oct 2006, at 23:29, Daniel P. Berrange wrote:


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

Is that over complicating the login protocol, at least for user name and password? Then we will have to keep track of not only authenticated sessions, but also login sessions.


   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.

Could we just add a new login_with_kerberos_... call to the API for that and any other method that people can come up with?


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


Well, the problem I ran into is that every distro has their own custom PAM stack and any PAM stack we write will only work on one distro and not another. I believe this is a distro packaging problem. But your concern is still valid, maybe we have to provide a PAM stack for one at least one distro. Let's fight to see which one that will be :)


 - 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

Definitely. I've only been testing with a local UNIX domain socket. Anything that goes over the network needs SSL encryption, but the API docs don't make any mention of this, presumably because it doesn't really fall into the API. My guess is we'll need to put some certificate configuration options in xend-config.sxp or run the Xen API on a different XMLRPC server than the one that currently serves xm.

Cheers,

Alastair



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