Spark appears to fall back to a non-sasl when authenticating


Spark appears to fallback to jabber:IQ:auth when GSSAPI is offered by the server, but can't be used. GSSAPI/SSO usually can not be used when the Kerberos server is unavailable or the client can not get a ticket ( ie client off the internal network). This is a problem because non-sasl authentication methods have been removed from openfire core starting in 4.1, and appears to have been removed from new version of smack.

In openfire if sasl.mechs is set to PLAIN,GSSAPI
In Spark, when SSO is selected, spark will authentication and use GSSAPI.
When SSO is not use, or can not be used because the Kerberos server is not available; the user should be able to disable SSO from spark, and authenticate using PLAIN. However when trying to do so authentication fails.

In Openfire, if sasl-mech is set to only PLAIN, than Spark with authenticate with only username and password as expected.

When using spark with smack3, and OF 4.02 sasl.mech set to PLAIN, GSSAPI; if SSO fails, a user can still authenticate after disabling SSO within Spark, and use their username and password (although using jabber:IQ:auth)


Microsoft Active Directory
Openfire 4.1
Spark (smack4)
sasl types offered by server PLAIN and GSSAPI.


August 20, 2016, 8:21 AM
August 19, 2016, 9:37 PM

Tested, and appears to be working as expected. Thanks!

Guus der Kinderen
August 19, 2016, 7:54 PM

So, if I understand this problem correctly:

  1. In an organization that supports SSO, Openfire configuration is modified to reflect this. This makes Openfire offer the GSSAPI SASL mechanism.

  2. It is possible for a user of such an organization to want to login without SSO (for instance, when they're out of office and have no access to SSO infrastructure).

  3. Spark will, when offered, always prefer the GSSAPI mechanism, even when SSO is not desired.

I've modified Spark in such a way that it will not consider the GSSAPI SASL mechanism when SSO is disabled. Changes are in





Guus der Kinderen