[JDEV] Moving passwords into LDAP (was Re: Storing passwords on Jabber server)

[jabber at msg.net]

David Waite writes:
> beyond all of this, there is still an issue on how authentication works 
> within the open-source Jabber server, and how it determines if a user 
> account exists (for instance, to decide if to put a message in offline, 
> or what to do with a presence subscription when a user is offline). 
> Currently, this is done doing a jabber:iq:auth request - this means that 
> if there is nothing to look up using an xdb jabber:iq:auth request, the 
> account will not work properly.

I gather that is what drove the design decisions of 'xdb_ldap', as a
xdb module, it will handle the jabber:iq:auth requests itself.

The other LDAP modules just skip over that issue, and assume that the
fields will have been populated with (real or bogus) data by mod_register.
 
> jabber at msg.net wrote:
> >>>'mod_auth_ldap', and 'xdb_ldap'.  Of these, only 'mod_auth_ldap' appears to
> >>>be actively developed, and all three have scalability issues.
> >>>
> >>What scalability issues? I'm sure I could think of a couple (the auth
> >>module blocking its single thread being the most obvious), but you sound
> >>like you've done a bit more investigation into this than I have. If you
> >>have any suggestions as to how to improve the module, I'd like to hear
> >>it :)
> >>
> >
> >>From xdb_ldap.README:
> >	jabber makes a lot of authentication request when an
> >	user logs (4 requests : one auth:get, two auth:0k:get and one
> >	auth:0k:set) in and binding to the LDAP server takes a lot of time.
> >
> >And if you use SSL, then the startTLS mechanism adds even more overhead
> >to the initial TCP connection, so you need to get into connection management,
> >or pushing the LDAP connectivity to a separate thread or a standalone app,
> >to work around the connection startup and blocking issues.
> >
> >>>OTOH, while 'mod_auth_ldap' never retrieves the user's plaintext password
> >>>from the server, and works without priviledged access to the LDAP server,
> >>>it only supports Jabber's password (no Digest, no 0K) authentication, where
> >>>the client sends their password in the clear. This isn't so bad if you can
> >>>ensure that your clients always use SSL to connect to the server.
> >>>
> >>Though _any_ not-SSL LDAP client suffers from this problem. I beleive
> >>someone has a patch in the works to SSL-enable mod_auth_ldap. The LDAP
> >>administrator at my organisation has a project underway to make
> >>LDAP-over-SSL available. Once this exists, I will probably look at
> >>adding SSL support to the module, which should fix the Jabber server <->
> >>LDAP server side, at least.
> >>
> >
> >I believe xdb_ldap went this road, including using SSL/TLS for authentication
> >to the LDAP server instead of storing the jabber server's LDAP credentials
> >in the xml configurations. The xdb_ldap package was forced to take into
> >accounts ome of the scalability issues due to the high overhead of SSL
> >session startup.
> >
> >If you take a look at xdb_ldap, it is _not_ using the user's existing LDAP
> >credentials for authentication, instead it is simply using LDAP as an XDB
> >backend for the authentication token, hash and the VCARD-temp data, by
> >using a custom objectClass derived from inetOrgPerson.
> >
> >
> >>Though there's still the plaintext password being handed from the Jabber
> >>client to the server, which unfortunately, isn't quite so easy to fix.
> >>
> >
> >Actually, what I was thinking about was turning off port 5222 and mandating
> >users to connect with SSL-enabled jabber clients (port 5223), which improves
> >the client-to-server plaintext password issue, though there are still some
> >concerns (due to weak SSL implementations in clients).
> > 
> >Kevin Kadow
> >MSG.Net, Inc.
> >_______________________________________________
> >jdev mailing list
> >jdev at jabber.org
> >http://mailman.jabber.org/listinfo/jdev
> >
> 
> 
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
>