| DJabberd authentication system |
[Apr. 13th, 2006|12:02 am]
Brad Fitzpatrick
|
With  hachi's LDAP wizardry and some ghetto Perl, I got the SixApart chat server up today. I subclassed the SQLite RosterStorage plugin and made it so when any employee logs in, it adds to their roster any employee that they're missing. Further nickname changes and group modifications are respected (that falls through to the SQLite layer), as well as the addition of non-SixApart JIDs, but the roster must always contain at least all employees, and automatically in the two-way approved state for presence. No more asking the new employee what his/her AIM name is, then going through the approval "add me to your whitelist!" crap.
But currently everybody's password is "password" because the authentication system isn't built out nicely yet.
I've been contemplating how to do it generically, so plugins can just declare what sort of authentication world they're living in, and DJabberd can then advertise on to the client the right auth modes which'll work with the underlying authn plugin.
In summary, I think the major worlds are:
1) The easiest, whereby client provides plaintext password (over SSL), and plugin can check it. A lot of times the client can provide the cleartext but the server doesn't know the cleartext because it's protected by, say, LDAP, or stored as only a digest on the server. Disadvantage is this requires SSL, but this is where a lot of auth plugins would have to go. And once client provides plaintext, DJabberd can then do whatever auth foo is required to test it.
2) But if the server knows the cleartext and can declare that, and provide the cleartext to Djabberd on request, a lot more auth options are available. (challenge-response stuff)
3) Finally, if user won't provide cleartext (no SSL) and server can't fetch the cleartext, then you hope there's an upstream auth provider that speaks SASL, and you just proxy SASL challenge/responses back and forth. A lot of LDAP servers let you speak SASL. I think ours at work will, but it's disabled? So I think I'll need to make our authn plugin do option 1) above, where we get plaintext passwords over SSL and then try to bind to the LDAP server. And that's what's inspired this post: DJabberd currently doesn't do SASL, and doesn't ask for cleartext passwords ever (when it advertises auth methods).
But too tired. Just dumping thoughts.
What other auth types am I missing that don't fit into those 3 categories? |
|
