Re: [gtk-vnc-devel] auth patch

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

On Fri, Jun 22, 2007 at 09:53:27AM -0500, Anthony Liguori wrote:
> Daniel P. Berrange wrote:
> >On Wed, Jun 20, 2007 at 11:52:48PM -0300, Jonh Wendell wrote:
> >  
> >>Hi folks.
> >>
> >>Here is the initial draft for the authentication on gtk-vnc.
> >>Well, i'd like to comment it here, but it's too late and i need to
> >>sleep :)
> >>    
> >
> >I'm not sure I like the way the auth stuff is handled here. You are
> >requiring that the application choose the desired auth scheme prior
> >to calling gvnc_go(). How can the app choose a suitable auth scheme
> >if we haven't asked the server what auth schemes it supports yet ?
> >  
> 
> Hrm, I misread the original patch.  I agree that a signal needs to be 
> emitted when the server presents the auth type.
> 
> Thinking about it now though, there may be something else to consider.
> 
> IIRC, for RFB 3.8, the server presents a set of potential auth types, 
> and then the user chooses the one he wants to use and sends it back to 
> the server.  I think any interface we have has to allow:

This is exactly what I was trying to described below....

> 1) Notify user that the server requires auth

Emit a signal

> 2) A mechanism for the user to enumerate the auth types supported by the 
> server

A parameter to the signal

> 3) A mechanism for the user to choose the auth type
> 4) A mechanism for the user to provide the required credentials for the 
> auth type.
>
> You could probably combined steps 3 & 4 by making setting the 
> credentials implicitly choose the auth type.

No that won't work since there's several auth types which all
acccept a password. And several auth types which don't have
explicitly specified credentials (eg, x509 keys are read off
disk out-of-band).

I think probably want

  gvnc_set_credential_password(value)
  gvnc_set_credential_username(value)
  ....

Or a generic

   gvnc_set_credential(type, value)

And then the

   gvnc_auth(type)

which would  validate the required credentials for 'type' had been
set, and then continue the auth process as described below...

> >The kind of thing I think may work better is that 'gvnc_new' runs
> >the protocol upto the point where server has sent back its list of
> >supported auth types. It then emits a signal 'auth-choice' passing
> >the list of auth types as parameters. The application can listen
> >for this signal decide what auth todo, and then call 'gvnc_auth'
> >to continue the protocol. If it was a traditional auth type, after
> >finishing auth it would emit a signal 'auth-result' either failed
> >or success. Alternatively if the app choose VeNCrypt as the auth 
> >type, we'd have to emit a second signal 'subauth-choice' again
> >passing a list of support auth types given by the server. The app
> >chooses the sub-auth type, and then runs gvnc_subauth() finally
> >emitting an 'auth-result' signal too.  Once the app has a successful
> >auth-result, signal received it can call into  gvnc_run() to do
> >the main event loop.
> >
> >
> >  1.  gvnc_new()
> >        - Emits auth-choice signal with list of schemes
> >  2.  gvnc_auth(scheme)
> >        a. Emits auth-result  with boolean / message
> >        b. Emits subauth-choice with list of schemes
> >  3.  If doing subauth  gvnc_subauth(scheme)
> >        Emits auth-result with boolean / message
> >  4.  Upon a auth-result, gvnc_run()
> >        
> >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  -=|