[gtk-vnc-devel] PATCH 0/2: Authentication callback support

["Daniel P. Berrange" <berrange redhat com>]

The following two patches implement support for enhanced authentication
allowing the widget to callback into the application to get credentials
needed for authentication.

In implementing it I decided that, at this point in time, the application
itself really doesn't need to choose between the different authentication
types. So when receiving the list of supported auth types, gvnc calls back
into vnc_display. vnc_display decides upon the best auth type to use and
tells the gvnc widget its choice.

Now onto credentials...

The vnc_display module has an API for providing credential data in a
generic format:

   gboolean vnc_display_set_credential(VncDisplay *obj, int type, const gchar *data);

And currently two types of credential:

   typedef enum
   {
        VNC_DISPLAY_CREDENTIAL_PASSWORD,
        VNC_DISPLAY_CREDENTIAL_USERNAME,
   } VncDisplayCredential;

I expect to add more credentials for TLS stuf - a way to request the
neccessary certificates

The implenentation of this method, simply passes the credentials down into
the gvnc module straight away. The application can set credentials ahead of 
time if it has them available.

When the gvnc module is told what auth type has been chosen, then it figures
out what credentials are required for this type. If the credential has not
already been set ahead of time, it triggers a callback to vnc_display, which
in turn emits a GTK signal. 

The application signal handler can call work in blocking mode and call the
vnc_display_set_credential function straight away - I call this synchronous
mode. In this case, when the signal handler completes, the gvnc callback 
also completes and it can carry on with auth process.  The application
signal handler can also work in non-blocking mode - eg the signal handler
can return without having set a credential. In this scenario the gvnc
widget will register a GSource which waits for a credential to be set. The
application can now go off & do whatever it has to do get credential and
when it finally calls vnc_display_set_credential, gvnc will get out of its
wait state & carry on with auth.  At any time, the app can also call the
vnc_display_close method which will simply set the 'has_error' flasg causing
the connection to be terminated.

So we have essentially 3 modes for provoiding credentials:

  - Ahead of time
  - Synchronously from the vnc-auth-credential signal handler
  - Asychronously at some point after vnc-auth-credential signal handler

If multiple credentials are required, you'll get one  vnc-auth-credential
signal emitted per credential, in sequence.

We now have 3 state signals too

  - vnc-connected  - emited once the basic TCP connection is established
  - vnc-initialized - emited once the protocol handshake & auth completes
  - vnc-disconnected - emitted when the connection shuts down

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