Re: [Qemu-devel] Re: [RFC 0/7]: Add VNC connect/disconnect events
On Tue, Jan 12, 2010 at 04:28:46PM -0600, Anthony Liguori wrote: On 01/12/2010 03:28 PM, Luiz Capitulino wrote: On Mon, 11 Jan 2010 13:55:19 + Daniel P. Berrangeberra...@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. That is a good point, and if we have the three events at time of 'connect', 'initialized' and 'disconnected', then if a mgmt app sees a 'disconnect' but no 'initialized' event, it knows the authentication was unsuccessful so do not need an explicit flag for that. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
[Qemu-devel] Re: [RFC 0/7]: Add VNC connect/disconnect events
On Mon, 11 Jan 2010 13:55:19 + Daniel P. Berrange berra...@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.
Re: [Qemu-devel] Re: [RFC 0/7]: Add VNC connect/disconnect events
On 01/12/2010 03:28 PM, Luiz Capitulino wrote: On Mon, 11 Jan 2010 13:55:19 + Daniel P. Berrangeberra...@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 |
[Qemu-devel] Re: [RFC 0/7]: Add VNC connect/disconnect events
On Fri, Jan 08, 2010 at 07:47:09PM -0200, Luiz Capitulino wrote: Hi there, This series contains two related changes. First a small cleanup is done in the current 'query-vnc' command, then two new QMP asynchronous events are introduced: VNC connect and disconnect. That's, everytime a VNC client connects or disconnects from QEMU, the QMP client will get full VNC client and VNC server info. There's one problem though and that's why this series is a RFC. The connection is a two step procedure if an authentication mechism is enabled. First the client establishes the connection then it authenticates. Currently, 'info vnc' and 'query-vnc' will show client information as soon as it establishes the connection even if the client didn't autheticate yet. This series changes that. Now, if an authentication mechanism is enabled, client information will only be available _after_ it has authenticated. Also, the connect/disconnect events are only emitted after the authentication step. There's a way to fix this and add the old behavior back, but we'll need one additional event (say CONNECT_AUTH) and the client will have to look at the server info to learn that a disconnection happened before authentication. Hmm, I had not considered the timing problems when I discussed this with you previously. I think it is important to separate the connect event from the authentication event, because a mgmt application using QEMU may want to see clients connecting even if they abort/delay before authenticating, 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 Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
