[jdev] Login with SASL credentials unrelated to domain username

[Aaron Kryptokos]

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 at 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 'joe at example.com.'

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 
'http://www.google.com/talk/protocol/auth' 
(http://code.google.com/apis/talk/jep_extensions/jid_domain_change.html), 
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?