[Standards] SASL Plain - AuthID - Bare JID or User Name?

Matthias Wimmer m at tthias.eu
Tue Feb 6 20:06:15 UTC 2007

Hi Chris!

I just had this discussion with Remko the last days.

Chris Mullins schrieb:
> We just ran into a problem doing Authentication with WildFire using the 
> Open Source SoapBox Framework and SASL Plain.
> The SoapBox Framework is using a bare JID (“user at server”) as the authid 
> that’s passed across the link. The Jive server is expecting only a user 
> name (“user”).
> The RFC doesn’t really say either way, and I figure this is a good 
> chance to get it clarified.
> (The SoapBox Framework now can do both, but I would sure prefer just one 
> or the other)

The basic problem is, that most current client implementations assume, 
that for authorization as user at server, they have to authenticate as user 
"user" in realm "server". So often you cannot set which username in 
which realm the client should use to authenticate at the server. - It is 
just automatically created from the JID you enter in the client, that 
you want to use.

While this assumption will work with most current server installations, 
it is nothing that is required to be supported by the server. Reading 
the SASL spec I would say that the authentication identity is nothing 
that is defined by the XMPP protocol, but just an identity a user has 
credentials for. Just the authorization id is necessarily a JabberID. 
The authentication ids that are used by a server are dependent on the 
authentication backend it uses.

E.g. a server might use the realm to know which authentication backend 
server has to be used, and because it supports virtual hosting but each 
backend server is responsible for multiple domains, it uses usernames of 
type user%server. So if the user owning the account "mawis at example.org" 
has its credentials stored on "useraccounts.example.com" it might 
authenticate as username="mawis%example.org", 
realm="useraccounts.example.com", authzid="mawis at example.org".

Remko and I concluded that for building an easy to use UI, it is okay to 
have the client doing a default mapping of JabberID to username and 
realm, but that a client cannot expect that to work and should provide a 
way that an experienced user is able to configure the username and realm 

So back to your question if "username" or "username at server" should be 
used as the authid in PLAIN:
1. It's the servers decission, it may even require to use a different 
username (e.g. "username%server").
2. RFC 3920, 6.1, rule 6 specifies what a server should use as the 
username for a client Jabebr account: "If provision of a 'simple 
username' is supported by the selected SASL mechanism [...], during 
authentication the initiating entity SHOULD provide as the simple 
username [...] its registered account name (user or node name as 
contained in an XMPP node identifier) in the case of client-to-server 
communications." [1]

Meaning that when PLAIN is used to authenticate with the Jabber server, 
the default behaviour would be to have a username of just the node and 
not the full JID.

But there are good reasons why we cannot require this. If we would make 
it a MUST that the the node is used as the username in PLAIN, we could 
not offer the PLAIN mechanism on servers, that support virtual hosting. 
(Note: you cannot use the value of the stream root to attribute to know 
the domain, as the to attribute on the stream root matches the domain 
part of the JID being the authorization ID, not the domain of the 
"authentication ID")


[1] Well this suggests that it's the client that decides which username 
is used to authenticate, but by practical logic and by the SASL spec its 
the server that has to decide which usernames are valid and are able to 
authenticate as which user.

Matthias Wimmer      Fon +49-700 77 00 77 70
Züricher Str. 243    Fax +49-89 95 89 91 56
81476 München        http://ma.tthias.eu/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4263 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070206/536d43cb/attachment.bin>

More information about the Standards mailing list