[jdev] Username-based SASL Mechanisms

[Artur Hefczyc]

In the original RFC the 'from' attribute is used differently:
"SHOULD be used only in the XML stream header from the receiving  
entity to the initiating entity"
while the bis allows for using the attribute by the initiating entity  
as well.

This is why most current clients don't put this attribute in the  
stream opening element
because they should not have done this before.
I  still think plain password authentication is the best way to go. Of  
course you must
set TLS to 'required' and make sure it is used. Then user passwords  
are safe.

Google does it this way too...

Artur

On 31 Oct 2008, at 15:38, Jonathan Dickinson wrote:

> Oops, sorry, wrong attribute :). Got my components and users mixed  
> up. The from was actually in the original spec, so that's why I  
> think something is awry with the clients.
>
> My problem is that some of our clients don't do stuff over SSL  
> (GASP!), so plain-text is a no-no, but a really good idea none-the- 
> less. I think I will go on the from attribute, if not there list  
> everything possible.
>
>> -----Original Message-----
>> From: jdev-bounces at jabber.org [mailto:jdev-bounces at jabber.org] On
>> Behalf Of Artur Hefczyc
>> Sent: Friday, October 31, 2008 4:30 PM
>> To: Jabber/XMPP software development list
>> Subject: Re: [jdev] Username-based SASL Mechanisms
>>
>> Hi,
>>
>> The 'to' attribute contains hostname only in the client to server
>> stream initialization and while
>> the client SHOULD set it it might not. Even if the client sets the
>> domain name it is not enough
>> for you to determine it.
>>
>> Version bis8 of the RFC introduces 'from' attribute which might be
>> exactly what you are looking
>> for assuming it is adopted by all clients soon:
>> http://xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-08.html
>>
>> Otherwise I don't really see how you could do what you want. Maybe
>> enforcing PLAIN-Text
>> password authentication either sasl or non-sasl for all users and  
>> then
>> using appropriate
>> authentication back-end by the server based on the user name would be
>> the best solution.
>> This is probably what I would do.
>>
>> Artur
>>
>> On 31 Oct 2008, at 14:38, Jonathan Dickinson wrote:
>>
>>> Hi All,
>>>
>>> This is a rather strange one. Is there any support for determining
>>> SASL mechanisms based on the user's name? I [will] have a bunch of
>>> authentication providers, such as EXTERNAL, SQL, SAP, NTLM,
>>> Kerberos, Open-Id etc. These can be located on the component itself
>>> or on another component on the network: it doesn't matter (ooh, you
>>> should see my framework :)). The thing that I worry about is that
>>> obviously some components won't support other authentication
>>> mechanisms (NTLM is a good example of this): so if I just query them
>>> verbatim for mechanisms there is no guarantee that the client will
>>> be able to use that mechanism to log in (e.g. Joe might be on the
>>> domain, but not in the SQL DB, failure if he tries to use DIGEST-MD5
>>> - his client may even always fail to log in).
>>>
>>> I thought that I could use the "to" attribute on the <stream:stream>
>>> tag, but another problem arises: most of the blumming client's I
>>> have analyzed using my server don't put this in the start tag: I am
>>> sure there is a reason I missed on the mailing list (is there?).
>>>
>>> I basically want to say to the components, "does anyone know this
>>> guy? How do I talk to him?" and if they respond I can aggregate the
>>> results, if not I can use a predefined list of mechanisms (to fool
>>> harvesters/hackers).
>>>
>>> Maybe I could leave it up to the users to complain to the
>>> misbehaving client developers?
>>>
>>> Thanks guys.
>>> _______________________________________________
>>> JDev mailing list
>>> FAQ: http://www.jabber.org/discussion-lists/jdev-faq
>>> Forum: http://www.jabberforum.org/forumdisplay.php?f=20
>>> Info: http://mail.jabber.org/mailman/listinfo/jdev
>>> Unsubscribe: JDev-unsubscribe at jabber.org
>>> _______________________________________________
>>
>> Artur
>> --
>> Artur Hefczyc
>> http://www.tigase.org/
>> http://artur.hefczyc.net/
>>
>> _______________________________________________
>> JDev mailing list
>> FAQ: http://www.jabber.org/discussion-lists/jdev-faq
>> Forum: http://www.jabberforum.org/forumdisplay.php?f=20
>> Info: http://mail.jabber.org/mailman/listinfo/jdev
>> Unsubscribe: JDev-unsubscribe at jabber.org
>> _______________________________________________
> _______________________________________________
> JDev mailing list
> FAQ: http://www.jabber.org/discussion-lists/jdev-faq
> Forum: http://www.jabberforum.org/forumdisplay.php?f=20
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
> _______________________________________________

Artur
-- 
Artur Hefczyc
http://www.tigase.org/
http://artur.hefczyc.net/