The missing parameters is an easy fix, I'll commit those changes for the
java viewer tonight (FYI, the Fltk viewer does not currently have those
parameters so if you need that functionality you should submit a feature
request to get them added).
As for password-less authentication, you know that X509none just uses X509
certificates to check the validity of the endpoints, right? It does not
prevent a user with a valid (ie: non-revoked) certificate from accessing
another user's session. Although I guess you could probably do something
like use a different CA to generate each user (or group of users)
certificate and thus limit access, but for anything other than a small
number of users this is likely to become difficult to manage...
-brian
On Fri, Dec 2, 2011 at 9:45 AM, Dan Garton <dan.gar...@gmail.com> wrote:
> Many thanks for your replies, just catching up now ....
>
> On 30 November 2011 19:05, Martin Koegler <mkoeg...@auto.tuwien.ac.at>wrote:
>
>>
>> > This mandates a minimum of a secure authentication stage, and then the
>> > client can be configured (but not forced) to encrypt the session
>> traffic.
>>
>> No. The client may choose between one of them. Either the session is
>> unencrypted (VNCAuth) or using the VeNcrypt+TLSVnc protocol (encrypted).
>
>
> Understood.
> This works in my situation as follows for the 2 different clients I am
> employing:
> 1) Tiger VncViewer.jar:
> - uses TLSVnc
> 2) noVNC:
> - does authentication with VNCAuth, and then session traffic is SSL
> encrypted using websockify
> ie. *noVNC*<----ssl---->*websockify*<---clear--->*tiger_server*
> which I think is OK as long as the communication between the websockify
> proxy and the tiger server is on a trusted network.
>
>
>> I'm not aware of any transparent signon. TigerVNC only allows:
>> * No authentification
>> * Classic VNC authentification
>> * Authentification with username/password (default authentification
>> provider
>> is the system authentification)
>>
>> It would be possible to extend SSecurityTLS/CSecurityTLS to send/verify
>> client
>> certificates and use this with X509None. This would result in a
>> passwordless
>> login solution based on certificates - but you would have to extend the
>> code.
>
>
> Ok, I must admit this has confused me a bit.
>
> Your email at
> http://www.mail-archive.com/tigervnc-devel@lists.sourceforge.net/msg01013.html
> suggested
> to me that X509None *already* allows for a passwordless login based on
> certificates, and you also listed the options used on both server and
> client sides for this.
> Though in a recent email conversation with Brian H, he told me that the
> trunk version of VncViewer.jar was still missing the parameter-passing
> logic for these options.
>
> I have a feeling that I'm still missing some understanding here though ...
> please feel free to correct me! :-)
>
> Thanks,
> Dan G
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Tigervnc-devel mailing list
> Tigervnc-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
>
>
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
