From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NUpEQ-0006sx-72 for qemu-devel@nongnu.org; Tue, 12 Jan 2010 17:28:58 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NUpEK-0006qP-Kz for qemu-devel@nongnu.org; Tue, 12 Jan 2010 17:28:57 -0500 Received: from [199.232.76.173] (port=60318 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NUpEK-0006qM-EA for qemu-devel@nongnu.org; Tue, 12 Jan 2010 17:28:52 -0500 Received: from qw-out-1920.google.com ([74.125.92.147]:45999) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NUpEK-000351-2A for qemu-devel@nongnu.org; Tue, 12 Jan 2010 17:28:52 -0500 Received: by qw-out-1920.google.com with SMTP id 14so148122qwa.4 for ; Tue, 12 Jan 2010 14:28:49 -0800 (PST) Message-ID: <4B4CF79E.5080604@codemonkey.ws> Date: Tue, 12 Jan 2010 16:28:46 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [RFC 0/7]: Add VNC connect/disconnect events References: <1262987236-2943-1-git-send-email-lcapitulino@redhat.com> <20100111135519.GA19479@redhat.com> <20100112192854.546aa02a@doriath> In-Reply-To: <20100112192854.546aa02a@doriath> Content-Type: multipart/alternative; boundary="------------020201030000030208050909" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org This is a multi-part message in MIME format. --------------020201030000030208050909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 01/12/2010 03:28 PM, Luiz Capitulino wrote: > On Mon, 11 Jan 2010 13:55:19 +0000 > "Daniel P. Berrange" wrote: > > >> So perhaps we should declare that the lifecycle is >> >> - CONNECT (provide IP / port details) >> - AUTHENTICATED (provide IP / port details + authenticated ID details >> eg x509 dname, or SASL usernsmae) >> - DISCONNECT (provide IP / port details) >> >> >> Obviously AUTHENTICATED may be optional if the client goes away >> immedaitely before trying auth. The AUTHENTICATED event probably >> also ought to allow for an indication of success vs failure so >> the app can see failed login attempts >> > I'm having an issue with the reporting of failure. > > Turns out we can have a few error conditions on login and they are > auth mechanism dependent. Also, as I'm not familiar with the code, > it's not always easy to get the ID information on failures. > > So, what is simple to do is to have an event called VNC_AUTHENTICATION, > it will have a 'authenticated' key which can be true or false. If it's true > authentication has been successful and ID information is available, > otherwise authentication has failed and only IP/port info is available. > > Of course that CONNECT and DISCONNECT events are also provided. > It might be worthwhile looking at the events that gtk-vnc supports. | VNC_CONNECTED, <- client has connected VNC_INITIALIZED,<- initialized is completed VNC_DISCONNECTED,<- client has disconnected VNC_AUTH_FAILURE, <- authorization has failed VNC_AUTH_UNSUPPORTED,<- authorization has failed (could not negotiate an auth type) Initialized can provide you all of the credential information. I think it's stronger than AUTHENTICATED because authentication alone does not imply that a session is active. Initialized tells a listener that at the moment this is received, the VNC session is active. If I'm a management tool, that's the thing I'm likely interested in. Regards, Anthony Liguori | --------------020201030000030208050909 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 01/12/2010 03:28 PM, Luiz Capitulino wrote: 
On Mon, 11 Jan 2010 13:55:19 +0000
"Daniel P. Berrange" <berrange@redhat.com> wrote:

  
So perhaps we should declare that the lifecycle is

  -  CONNECT       (provide IP / port details)
  -  AUTHENTICATED (provide IP / port details + authenticated ID details
                    eg x509 dname, or SASL usernsmae)
  -  DISCONNECT    (provide IP / port details)


Obviously AUTHENTICATED may be optional if the client goes away
immedaitely before trying auth. The AUTHENTICATED event probably
also ought to allow for an indication of success vs failure so 
the app can see failed login attempts
    
 I'm having an issue with the reporting of failure.

 Turns out we can have a few error conditions on login and they are
auth mechanism dependent. Also, as I'm not familiar with the code,
it's not always easy to get the ID information on failures.

 So, what is simple to do is to have an event called VNC_AUTHENTICATION,
it will have a 'authenticated' key which can be true or false. If it's true
authentication has been successful and ID information is available,
otherwise authentication has failed and only IP/port info is available.

 Of course that CONNECT and DISCONNECT events are also provided.

It might be worthwhile looking at the events that gtk-vnc supports.

	VNC_CONNECTED,   <-  client has connected
	VNC_INITIALIZED,  <- initialized is completed
	VNC_DISCONNECTED, <- client has disconnected
	VNC_AUTH_FAILURE, <- authorization has failed
	VNC_AUTH_UNSUPPORTED,  <- authorization has failed (could not negotiate an auth type)

Initialized can provide you all of the credential information.  I think it's stronger than AUTHENTICATED because authentication alone does not imply that a session is active.  Initialized tells a listener that at the moment this is received, the VNC session is active.  If I'm a management tool, that's the thing I'm likely interested in.

Regards,

Anthony Liguori


--------------020201030000030208050909--