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

[jabber at msg.net]

> > '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.