It would seem that Spark does not work with SSO when using SRV records to identify the XMPP Server.
What should happen is:
Spark looks up the SRV records to identify the server address
Spark does a reverse lookup on the server address and uses that as the security principal (xmpp/reverselookup@REALM)
What actually happens is:
Spark does a reverse lookup on the domain name in which the SRV records exists and constructs the security principal from that (xmpp/reverselookupofdomain@REALM)
This breaks SSO in my environment (I configure my server to be the same as my internal AD domain).
Rather than identifying the correct server, it just does a lookup on the domain name, which actually returns a list of domain controllers for the domain. Obviously this isn’'t good, as the security principal name changes every time I do it!
This is actually a bug in Smack, which should be fixed in subversion now, and perhaps even the latest release (Im not sure). It will make its way to Spark very soon.
We’‘re going to update the Spark 2.5.3 branch so that it includes Smack 3.0.3. We just finished week 1 of QA on both those releases, so they’'ll be out in just less than 2 weeks.
I’‘m not positive that we’‘re going to release a beta2, but it sounds like getting this issue fixed would help with SSO testing, so it’'s probably worth it. If we do a beta2, it would be this week, so stay tuned.
It’'d really help if you could; I setup a lab environment for SSO testing and have it working with my regular server, but not my production server which uses SRV records.