Projects
/
OF-1195

JDBCAuthProvider does not play nice with SCRAM

Description

When Openfire is configured to use a custom JDBC integration, the recently added SCRAM implementation causes problems (without a salt, it tries to reset a password, which can be read-only through the provider - if the password is not read-only, the newly generated password will probably be unusable by other systems, as it was regenerated with a salt only in the Openfire database)

I'm seeing this in SASLAuthentication#getSupportedMechanisms():

Should this be an "or" condition instead, perhaps combined with a change where JDBCAuthProvider#isScramSupported returns 'true' only when its fields allowUpdate == true and setPasswordSQL != null. Again, I'm not sure if resetting a password value outside of the Openfire is wise, when the salts used are not in that same database.

Environment

None

Acceptance Test - Entry

None

Activity

Show:
Garrett
November 22, 2016, 2:10 PM
Edited

This is a critical problem for our deployment, which version is the first this affects? Any timeline for 4.1.0 and/or a hotfix?

Anything I can do to help?

To clarify, we have a database with usernames and plaintext passwords (random strings created by us for internal use) and cannot auth anyone logging in with 4.0.3 - a workaround would be just as good as a fix for our purposes

Thanks

Dave Cridland
December 18, 2016, 4:53 PM

Did you find a workaround for this, or is it fixed in 4.1.0 Beta?

Garrett
December 18, 2016, 5:17 PM

In my case, I had to add a system property "sasl.mechs" to "PLAIN" to have it auth properly, so this appears to be fixed I suppose - not sure about the person who initially had the problem, but things are working for me.

Dave Cridland
December 21, 2016, 1:31 PM

No, that's a workaround, but I think the suggested fix is right. PR made.

Fixed

Assignee

Dave Cridland

Reporter

Guus der Kinderen

Labels

None

Expected Effort

None

Ignite Forum URL

None

Fix versions

Priority

Major
Configure