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

Mridul mridul at sun.com
Fri Feb 9 06:55:50 UTC 2007

Matthias Wimmer wrote:
> Hi Mirdul!
> Mridul schrieb:
>> I need not have mentioned about server also hosting sun.com - which 
>> lead to the confusion I guess (that was just a snippet off a 
>> deployment I was testing with hosted domains & jid escaping).
>> The way I meant it was : the user id is the mailid attribute in ldap.
>> That is, jid would be mridul\40sun.com at test.com (escaped as per xep 
>> 106).
>> User id would be mridul at sun.com.
>> In the above example, mridul at sun.com does not mean mridul wants to 
>> log into sun.com domain.
>> It means "mridul at sun.com" is the user name who wants to log into 
>> test.com.
> The authentication identity does not have to tell the server to which 
> domain it wants to log in. (That's not the task of authentication, but 
> of authorization - so this is done in the authorization id.) If 
> mridul at sun.com wants to log in to an account on test.com it would use 
> (in my proposed deployment):
> stream root: to='test.com' (mandated)
> SASL PLAIN: account at test.com \0 mridul at sun.com \0 mridulsPassword 
> (installation/implementation specific)

Hi Matthias,

Authorization id's domain is same as 'to' - which identifies the domain 
you want to authenticate to.
In a hosted domain deployment case, this is used by us to identify the 
realm - not what is present in the user id itself.
What is present in the uid is treated as an opaque string by the server 
- which is passed on to the spi which does the actual auth for that 
realm (realm is what server derived from 'to') : the uid could be a dn, 
cn, some hash, etc - server does not interpret uid in any way.
With this, clients or spi impl's need not try to derive things from the 
uid to identify the realm.

I guess the incompleteness in our interfaces from a strict SASL point of 
view (which confused me w.r.t what you were saying initially) is that we 
do not allow proxy authentication, and so we do not pass on authzid. The 
spi impl for auth tells us what the user is to be authorized as: so you 
cant give admin uid/password and log in as me.

Thanks for the clarification - it cleared up some things for me :-)

> But you may express the username any other way the administrator of 
> the server wants. E.g. a server might also be configured, that you 
> pass a complete LDAP DN as the username. In that case you would log in 
> to the server using the following data:
> stream root: to='test.com'
> SASL PLAIN: account at test.com \0 mail=mridul at sun.com,o=sun,c=us \0 pass
> It is server deployment specific what has to be passed as the 
> authentication id. That is a real important thing! We have a standard 
> mapping ("SHOULD" in the RFC) that typically you use just the node 
> value as the simple username if a SASL mechanism supports a simple 
> username. But a server is free to deploy other semantics for a 
> username, if it is required to do this to use his authentication backend.
> For an implementation in a client this means, that for easy 
> configuring you typically will enter just the JID of the account you 
> want to authorize as. (e.g. "account at test.com") If you do not 
> configure any additional settings, it the client will use "account" as 
> the simple username it authenticates as.
> But as this might not be right for some servers, the client needs to 
> allow the user to setup a different authentication id, that it will 
> use to authenticate at. So for the last example I made above, you 
> would for example configure something like this:
> JabberID: account at test.com
> Password: pass
> [X] use non-default authentication id
> username: mail=mridul at sun.com,o=sun,c=us
> realm: ldap.sun.com        <-- not used when authenticating using PLAIN
> Remko told me, that Psi will have such a UI in the future.
>> Just assume that mail id attribute is used as user id.
>> And server is hosting a domain != mail domain.
> I have to admit, that I don't see your problems yet. Please explain me 
> where you found a problem with this.
> Matthias

More information about the Standards mailing list