[jdev] Username-based SASL Mechanisms

[Jonathan Dickinson]

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
> _______________________________________________