DIGEST-MD5 (and so some degree GSSAPI), allows you to authenticate with separate credentials from the account you're authorizing to. So it's 100% valid in the XMPP world to login into the <a href="mailto:joe@example.com">joe@example.com</a> xmpp account using a username of bob and bob's password. <div class="gmail_quote">On Sun, Nov 15, 2009 at 4:01 AM, Aaron Kryptokos <<a href="mailto:aaronkryptokos6@aaronwl.com">aaronkryptokos6@aaronwl.com</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Hi, I'm working on an XMPP server im interface to a closed user community. Currently, users can only participate in conversations through the community software, which can be inconvenient if communication with contacts is all that is desired. However, I'm having some trouble mapping XMPP-style authentication into our authentication scheme. In our system, the client's public username at our domain has no particular relationship to their private authentication identity. That is, the username portion of username@domain does not match the SASL authcid. The problem is that all of the XMPP-based IM clients that I looked at typically ask only two questions: What is your JID? What is your password? Some ask for username separately from domain, and many allow a server hostname other than the domain, but none (that I tried) seem to allow an authentication username that differs from the JID username. The net effect is that the client's idea of what its JID is is incorrect. The reason I think that this type of scheme is reasonable is that it works just fine with software for other standard messaging protocols, such as SMTP, IMAP, and POP3. In those protocols, the authentication credentials provided at login (with SASL or otherwise) have no particular relationship with the email address. For instance, it's totally trivial to set up any mail client to authenticate with the IMAP and SMTP servers as 'bob' but send messages as '<a href="mailto:joe@example.com" target="_blank">joe@example.com</a>.' I'm not totally sure what the impact of this is. Some clients seem to at least partially understand having their bare JID reassigned during resource binding, particularly those that support '<a href="http://www.google.com/talk/protocol/auth" target="_blank">http://www.google.com/talk/protocol/auth</a>' (<a href="http://code.google.com/apis/talk/jep_extensions/jid_domain_change.html" target="_blank">http://code.google.com/apis/talk/jep_extensions/jid_domain_change.html</a>), such as Pidgin. However, even on these clients, the JID is still usually displayed incorrectly in the accounts page. At the very least, this could cause substantial user confusion. In addition, in our system, we consider authentication credentials to be somewhat private information, and avoiding their leakage is probably a good thing. Have any other sites or software packages found ways to work around this issue? Does anyone have any advice on how to handle this situation? _______________________________________________ JDev mailing list Forum: <a href="http://www.jabberforum.org/forumdisplay.php?f=20" target="_blank">http://www.jabberforum.org/forumdisplay.php?f=20</a> Info: <a href="http://mail.jabber.org/mailman/listinfo/jdev" target="_blank">http://mail.jabber.org/mailman/listinfo/jdev</a> Unsubscribe: <a href="mailto:JDev-unsubscribe@jabber.org" target="_blank">JDev-unsubscribe@jabber.org</a> _______________________________________________ </blockquote></div> -- - Norman Rasmussen - Email: <a href="mailto:norman@rasmussen.co.za">norman@rasmussen.co.za</a> - Home page: <a href="http://norman.rasmussen.co.za/">http://norman.rasmussen.co.za/</a>