Ingo is currently unable to access e-mail so he has asked me to resend these on his account:
-------- Original Message --------
Subject: RE: [jitsi-dev] kerberos / GSSAPI sign in for XMPP
Date: Fri, 4 Oct 2013 14:53:34 +0000
From: Ingo Bauersachs
GSSAPI for XMPP itself shouldn't be a big problem - we already got the LoginStrategies for password and certificates, so GSSAPI should be implementable as a third option. I don't know how the GSSAPI provider works, but theoretically we should be able to intercept the password prompt for it just the same as it is done for the certificate based login.
On Windows, there should never be a login prompt (the ticket is obtained with the current Windows logon credentials) unless the client is not domain joined or in some other untrusted domain - in which case the GSSAPI doesn't make much sense anyway.
Mit freundlichen Grüssen
Maklerzentrum Schweiz AG
MSc FHNW in Computer Sciences
Informatik, System Integration
Tel. 0800 822 800
Fax 0800 822 801
Mob +41 76 515 60 43
Falls Sie diese Nachricht irrtümlicherweise erhalten haben, bitten wir Sie, die absendende Person zu kontaktieren und diese Nachricht mit allen Anhängen von Ihrem System zu löschen.
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of David Mansfield
Sent: Freitag, 27. September 2013 14:54
Subject: [jitsi-dev] kerberos / GSSAPI sign in for XMPP
I was investigating various XMPP clients to find if any support GSSAPI, and as it turns out, jitsi does by virtue of the smack library used for the xmpp implementation (smack is used by ignite's spark xmpp client, which also supports GSSAPI).
The good news is, it works (with openfire configured to do SASL/GSSAPI). Note this works on linux with java 1.7 (not with 1.6 for some weird reason) AND on windows with some registry tweaking.
The not so great news is that there are some problems with getting it to work smoothly. Just wondering if anyone has any thoughts about how to fix this. I'd be willing to do some legwork but I need a temperature check first.
1) A file "gss.conf" needs to be created by hand in /usr/share/jitsi (or wherever the working directory is, according to the wrapper script).
This file, for me, contains:
com.sun.security.auth.module.Krb5LoginModule required useTicketCache=true;
2) Assuming a valid tgt exists, jitsi can authenticate perfectly, however it still requires a password (which isn't used). It works fine to put "x" and check the save password checkbox. However, if the tgt ever expires or whatever, "x" will have to be saved again because jitsi will assume the saved password is bogus (which it is!).
3) If a valid tgt doesn't exist, the prompt for the password (see #2) doesn't have any affect on the actual authentication, which will take place in the terminal where jitsi was launched (ie. via stdin/stdout). So there will be two prompts, one bogus one that is pretty via the jitsi UI, and one ugly default one that you need a terminal window to use. Note in windows this is even uglier due to some strange interaction of stdin/stdout (or whatever they call in in windows) and the cmd.exe when jitsi has backgrounded itself - but it does still work.