powered by Jive Software

Spark SSO Improvements


Currently there are several limitations to Spark’s SSO implementation, especially on current windows systems like W7. There are currently two requirements:

  1. Session keys need to be sent in the Kerberos TGT: http://support.microsoft.com/kb/308339

  2. Spark needs to be run-as Administrator if UAC is enabled

Both of these requirements reduce the security of a user’s system and in an enterprise envrionment these may not even be allowed.

I’m looking for an XMPP client with working SSO (on W7) and a good user experience around MUC’s, I’ve been able to get Pidgin, Miranda-IM, and Spark working:

Pidgin - SSO requires external MIT Kerberos application which sometimes hangs and remote VPN users doesn’t work seamlessly. The MUC interface is cluttered and has too many menus.

Miranda-IM- SSO works seamlessly, just click on “Use Domain Login”, remote VPN users seamlessly reconnect once connected via VPN. However, the MUC interface is buried in several menus deep and isn’t very user friendly.

Spark - SSO requires the previously mentioned security settings and I haven’t tested over a VPN connection. The MUC interface works well, single menu to list the available chatrooms

Would it be possible to look at the way Miranda’s SSO implementation works and integrate it with Spark to remove the current limitations? The source code is available here: http://code.google.com/p/miranda/source/browse/


They’re not even on the same language. Miranda is C, Spark is Java based. So looking at the source won’t help much.

The second issue isn’t much of a problem, it only happens when user is local administrator and has UAC enabled. This is due to the way Windows 7 UAC handles the sessions. A simple way to sidestep this problem is to configure a scheduled task to launch on logon with elevated privileges.

They may not be the same language, but there must be API/libraries that may also be called by Java.

Does a scheduled task still present the UAC prompt?

I found Pandion also does SSO seamlessly, unfortunately the authors seem to have abandoned the project.


I am sorry, but we have no chance to implement these changes. An SSO implementation would require a dedicated ressource that works for a couple of weeks to sort out all issues. Frankly speaking, we do not have these ressources. The Spark 2.6 push was actually pushed forward by a company that wanted to pay back to the open source project. An SSO integration can not be done by non existing developers.