sounds like maybe a bug when openfire is running on linux. It might be worth trying the included jre instead of java7_79, but something tells me that prob wont work either!
Hello!
Where is the bug in this patch:
https://github.com/igniterealtime/Openfire/commit/3eadecb67daddbcaeb1dc76ec578ed 0f70e96ad8
Client can send empty response due to RFC 6120 6.4.2, but in second code block Openfire doesn’t verify received string length.
With this code SSO works at 3.10.2:
if (response.length() > 0) {
if (!BASE64_ENCODED.matcher(response).matches()) {
authenticationFailed(session, Failure.INCORRECT_ENCODING);
return Status.failed;
}
}
Patched Openfire.jar 3.10.2 for testing purposes:
Hi Kalchenko,
Thanks! Would you kindly consider submitting a pull request with this change or attaching a git diff of your suggested patch?
Sorry, i’m just a system administrator and don’t working with modern code tools properly
how about the line numbers where you edited this code? I am tagging @CSH on this message so he can provide some feedback on your suggested change.
365-370 lines in src/java/org/jivesoftware/openfire/net/SASLAuthentication.java
I would like to add, I just tested sso with no problems.
Server:
Centos 7 (fresh install)
Openfire 3.10.2 (fresh install from RPM)
Windows 2012r2 AD
Client:
Windows 8.1
Spark 2.7.1
I’ll try to set up a test ubuntu/Debian sometime to see if I can reproduce this
Hi,
Another test would be against Messages on Mac OS X by doing a kinit username@REALM, confirming you have a ticket with klist and then configuring Messages to use Kerberos/GSSAPI via the “use Kerberos v5 for authentication” tickbox in "Server Settings "-> “Accounts”
I’m poor and don’t have a mac to test with! lol
OK with that new Openfire.jar it seems to work! At least on my home Mac- will try it on my work machines (Mac + Linux) tomorrow but this looks promising!
Maybe this change has broken it?
https://github.com/igniterealtime/Openfire/commit/84e41fbea714f8a0902e627ff243d4 907df3d4dd
Last time I was in that class was before 3.9.3
Seems like you are sending an empty response:
but the current logic doesn’t allow it and assumes at least an equals sign ("=").
Empty content is not allowed in and but the spec is unclear about empty content in -
Yes, client (Miranda NG) send empty in reply to first like this:
[14:00:43 0690] [JABBER_1] (021E5DC8:1596) Data received
YGUGCSqGSIb3EgECAgIAb1YwVKADAgEFoQMCAQ +iSDBGoAMCAReiPwQ9M6bL3MGpW6xc/E+qlVvER5dfe1OgITN2hlue3Rt6Udc/tO0Q7USIQb8CL/ue+p 2vBbzCsTKQmThEXyRT5Q==
[14:00:43 0690] [JABBER_1] recvResult = 204
[14:00:43 0690] [JABBER_1] bytesParsed = 204
[14:00:43 0690] [JABBER_1] (021E5DC8:1596) Data sent
[14:00:43 0690] [JABBER_1] (021E5DC8:1596) Data received
When connects to 3.9.1, server sends another challenge in reply to empty response.
What about RFC - 6.4.3. Challenge-Response Sequence
The initiating entity responds to the challenge by sending a
element qualified by the
‘urn:ietf:params:xml:ns:xmpp-sasl’ namespace; this element MAY
contain XML character data (which MUST be generated in accordance
with the definition of the SASL mechanism chosen by the initiating
entity).
So this MAY contain data, but it not strict requirement for challenge\response phase, as i understand?
In initiation phase () it’s described:
6.4.2. Initiation
In order to begin the SASL negotiation, the initiating entity sends
an element qualified by the
‘urn:ietf:params:xml:ns:xmpp-sasl’ namespace and includes an
appropriate value for the ‘mechanism’ attribute, thus starting the
handshake for that particular authentication mechanism. This element
MAY contain XML character data (in SASL terminology, the "initial
response") if the mechanism supports or requires it. If the
initiating entity needs to send a zero-length initial response, it
MUST transmit the response as a single equals sign character (“=”),
which indicates that the response is present but contains no data.
Any updates for this issue? Will it be fixed to allow empty response from client?
@CSH please, give the answer - it will be fixed or we’ll need to patch every future openfire release manually?
I can’t use spark at workstations, another IM clients that sends empty response are broken too.
Many thanks! Will wait for next release
I’ve been unsuccessful at getting SSO to work as well using Windows Server 2008 R2 Enterprise, Windows 7 x64 Enterprise, Openfire 3.10.2, Spark 2.7.1. I was using Java 8u51 on my workstation downgraded to Java 7u79 and attempted to use the openfire.jar file provided above as a means of testing; still unable to log in. My client log file gives only this information after each attempt to sign in:
Aug 14, 2015 1:47:44 PM org.jivesoftware.spark.util.log.Log warning
WARNING: Exception in Login:
No response from the server.:
at org.jivesoftware.smack.NonSASLAuthentication.authenticate(NonSASLAuthentication .java:73)
at org.jivesoftware.smack.SASLAuthentication.authenticate(SASLAuthentication.java: 357)
at org.jivesoftware.smack.XMPPConnection.login(XMPPConnection.java:243)
at org.jivesoftware.LoginDialog$LoginPanel.login(LoginDialog.java:1065)
at org.jivesoftware.LoginDialog$LoginPanel.access$1400(LoginDialog.java:305)
at org.jivesoftware.LoginDialog$LoginPanel$4.construct(LoginDialog.java:837)
at org.jivesoftware.spark.util.SwingWorker$2.run(SwingWorker.java:141)
at java.lang.Thread.run(Unknown Source)
java.net.SocketException: Software caused connection abort: socket write error
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(Unknown Source)
at java.net.SocketOutputStream.write(Unknown Source)
at sun.security.ssl.OutputRecord.writeBuffer(Unknown Source)
at sun.security.ssl.OutputRecord.write(Unknown Source)
at sun.security.ssl.SSLSocketImpl.writeRecordInternal(Unknown Source)
at sun.security.ssl.SSLSocketImpl.writeRecord(Unknown Source)
at sun.security.ssl.AppOutputStream.write(Unknown Source)
at sun.nio.cs.StreamEncoder.writeBytes(Unknown Source)
at sun.nio.cs.StreamEncoder.implFlushBuffer(Unknown Source)
at sun.nio.cs.StreamEncoder.implFlush(Unknown Source)
at sun.nio.cs.StreamEncoder.flush(Unknown Source)
at java.io.OutputStreamWriter.flush(Unknown Source)
at java.io.BufferedWriter.flush(Unknown Source)
at org.jivesoftware.smack.PacketWriter.writePackets(PacketWriter.java:168)
at org.jivesoftware.smack.PacketWriter.access$000(PacketWriter.java:40)
at org.jivesoftware.smack.PacketWriter$1.run(PacketWriter.java:69)
stream:error (system-shutdown)
at org.jivesoftware.smack.PacketReader.parsePackets(PacketReader.java:251)
at org.jivesoftware.smack.PacketReader.access$000(PacketReader.java:46)
at org.jivesoftware.smack.PacketReader$1.run(PacketReader.java:72)
I had SSO working for roughly 1 day back in June. Completely unsure of what changed except that I believe I upgraded to 3.10.2 at that time which broke SSO. I can’t verify as I wasn’t worried about SSO implementation at that time; only recently having SSO be a requirement for our users. Not sure if my issue is related to this thread exactly; I’m not a software guy but this seems to be the best rabbit hole I’ve been down yet.
any help and/or direction would be greatly appreciated.
For anybody still having issues on this, I am curious to know what you have
xmpp.domain
xmpp.fqdn
set to. Trying to get this straightened out prior to a 3.10.3 release.
xmpp.domain = jbl.Com
xmpp.fqdn = application.jbl.com
Windows Server 2012 R2
Windows 7 ×64 client
Spark 2.7.3
Open fire 3.10.2
Don’t know if that helps or not. That is set up on my test environment. 1 physical server set up with 3 VM’s and a virtual switch