[Standards] SASL Plain - AuthID - Bare JID or User Name?
stpeter at jabber.org
Tue Feb 6 20:23:07 UTC 2007
Matthias Wimmer wrote:
> 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.
Yes, that's because the nature of the authcid (not authzid, sorry for my
earlier confusion) depends on the SASL mechanism used.
> 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." 
> 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.
I think that's correct -- according to RFC 4422 this is a "simple
username". But note what RFC 4013 (SASLprep) has to say about "simple
The profile is designed for use in Simple Authentication and Security
Layer ([SASL]) mechanisms, such as [PLAIN], [CRAM-MD5], and
[DIGEST-MD5]. It may be applicable where simple user names and
passwords are used. This profile is not intended for use in
preparing identity strings that are not simple user names (e.g.,
email addresses, domain names, distinguished names), or where
identity or password strings that are not character data, or require
different handling (e.g., case folding).
In fact we don't use SASLprep for authcids because even an XMPP node
identifier is not as simple as it seems. :-)
> 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.
Yes, so I think we can't say the authcid MUST be the node identifier.
> (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")
XMPP Standards Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards