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