In the SmackTestCase we have this call in setUp():
getConnection(i).login(currentUser, password, “Smack”);
The login method: “Logs in to the server using the strongest authentication mode supported by the server, then sets presence to available. If the server supports SASL authentication then the user will be authenticated using SASL if not Non-SASL authentication will be tried.”
What actually happens with my server is:
SASL authentication DIGEST-MD5 failed: invalid-authzid:
The messages when SASL MD5 is used are:
Y2hhcnNldD11dGYtOCx1c2VybmFtZT0idGVzdD EiLHJlYWxtPSJ4Y3AubG9jYWxob3N0Iixub25jZT0iNjUyOTM2OTE3MThhYWUxNjdmMjY4YWQzZmM4ZD k3MTAiLG5jPTAwMDAwMDAxLGNub25jZT0iY2dpWGdCbUxBMjRuSXBqMFYxSy9pMGNEZnZXNzJLUklQTn VzR2svRyIsZGlnZXN0LXVyaT0ieG1wcC94Y3AubG9jYWxob3N0IixtYXhidWY9NjU1MzYscmVzcG9uc2 U9NmE0OWRhZmVkN2QxNDc1YjZhNDk0YTMyYTVmZWYzZTIscW9wPWF1dGgsYXV0aHppZD0idGVzdDEi</ response>
cmVhbG09InhjcC5sb2NhbGhvc3QiLG5vbmNlPS I2NTI5MzY5MTcxOGFhZTE2N2YyNjhhZDNmYzhkOTcxMCIscW9wPSJhdXRoIixjaGFyc2V0PXV0Zi04LG FsZ29yaXRobT1tZDUtc2Vzcw==
Clearly my server does not like the authzid. Consulting with my colleagues has helped me understand that the authzid actually should not be sent except under very specific circumstances, which these do not seem to be.
It seems that Smack violates RFC 3920 § 6.1 bullet 7 (and RFC 6120 § 6.3.8). The authzid MUST NOT be included if the user does not wish to proxy (e.g. “admin” entity logs in but wishes to be “normal user A” entity) for promote (e.g. “normal user A” entity wishes to login as “admin” entity), which are scenarios that neither my server nor Smack, I think, support.
From RFC 3920 § 6.1:
- If the initiating entity wishes to act on behalf of another entity and the selected SASL mechanism supports transmission of an authorization identity, the initiating entity MUST provide an authorization identity during SASL negotiation. If the initiating entity does not wish to act on behalf of another entity, it MUST NOT provide an authorization identity. As specified in [SASL], the initiating entity MUST NOT provide an authorization identity unless the authorization identity is different from the default authorization identity derived from the authentication identity as described in [SASL]. If provided, the value of the authorization identity MUST be of the form (i.e., a domain identifier only) for servers and of the form node@domain (i.e., node identifier and domain identifier) for clients.
From RFC 6120 § 6.3.8:
An authorization identity is an OPTIONAL identity included by the initiating entity to specify an identity to act as (see Section 2 of [SASL]). In client-to-server streams, it would most likely be used by an administrator to perform some management task on behalf of another user, whereas in server-to-server streams it would most likely be used to specify a particular add-on service at an XMPP service (e.g., a multi-user chat server at conference.example.com that is hosted by the example.com XMPP service). If the initiating entity wishes to act on behalf of another entity and the selected SASL mechanism supports transmission of an authorization identity, the initiating entity MUST provide an authorization identity during SASL negotiation. If the initiating entity does not wish to act on behalf of another entity, it MUST NOT provide an authorization identity.
Do you have any thoughts on what the best way would be to address this issue?