This may simple be a case where the documentation is not clear. Configured a base Prosody,and set up mod_sasl with mod_imap.. Testing with a simple start of a stream, using a 'localhost' virtual. openssl s_client -starttls xmpp -connect localhost:5222 -quiet <stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" to="localhost" version="1.0" > <auth xmlns="urn:ietf:params:xml:ns:xmpp-sasl" mechanism="PLAIN"> [BASE64 encoded '\0username@domain\0password'] </auth> Result: User authenticated successfully, but username was invalid Tracked this all the way through to the nodeprep call .. But get lost there, to figure out why it is invalid. sm_make_authenticated(session, session.sasl_handler.username); Debug shows that it is using 'username@domain', and it fails exactly on: username = nodeprep(username); So, the problem is whether username should be in a different format at that point, or is this a problem with the 'domain' part, or is this a configuration issue. Be nice if the debug output could indicate the problem a bit more succintly..

In the email world it is common to have the full email address as username in SASL, while in the XMPP world only the localpart is commonly used. This complicates any interoperability like what mod_auth_imap (and mod_auth_dovecot) tries to do. You either have to rewrite the username somewhere, or receive username and password from the client and do a separate SASL exchange with the backend. 'username@domain' fails nodeprep because this validates only the 'username' part, and '@' is forbidden in XMPP JID localparts (unlike email where "this@that"@domain is perfectly legal). Note that once you connect a normal XMPP client, it will most likely send only the username in the SASL exchange, so then you have the opposite problem if the IMAP server expects username@domain Problems like this is why not much development goes on with these email-integration authentication modules. Setting 'auth_append_host = true' enables SASL username rewrite which appends the domain but limits you to the PLAIN mechanism. Hope this helps. Feel free to submit patches that improve the documentation. FWIW since the module shares some history and configuration options with https://modules.prosody.im/mod_auth_dovecot.html reading its documentation might help.

• tags Component-Community