?

Log in

No account? Create an account
DJabberd authentication system - brad's life — LiveJournal [entries|archive|friends|userinfo]
Brad Fitzpatrick

[ website | bradfitz.com ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

DJabberd authentication system [Apr. 13th, 2006|12:02 am]
Brad Fitzpatrick
[Tags|, ]

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?
LinkReply

Comments:
[User Picture]From: mart
2006-04-13 11:32 pm (UTC)

It's kinda lame that you can't do challenge-response auth without knowing the password. I had a similar problem with digest auth in my Wildfire integration at work, though our backend app that we're integrating with actually stores passwords in cleartext so in the end I just added a method to it where I pass the digest credentials to the app unmodified and it does the digest auth. A bit lame, but it works in my case. I assume Wildfire's LDAP auth provider only supports plaintext.

As Evan noted, there's also the wacky authentication mechanisms that aren't based on usernames and passwords at all. I handled this in our CMS at work (where OpenID was actually my “wacky test” for the architecture and is supported in our latest release!) by having the core system only know about userids and having several different modules that know how to map some arbitrary set of credentials onto a userid and vice-versa, but I don't think the Jabber protocol even supports such shenanigans, does it? As far as I'm aware the protocol is pretty set on having usernames and passwords. Maybe SASL helps though, I guess. I don't really know anything about it.

(Reply) (Thread)
From: (Anonymous)
2006-04-14 03:22 am (UTC)
I can guarantee that wildfire supports at the least MD5, and I think SSHA, crypt, SMD5, etc. We don't have any unencrypted passwords, and it works just fine. It does an anonymous search to get the DN, and then tries to bind to the server with that DN and the supplied password.

The problem we're currently having is that users will get disconnected from the server, but their client doesn't realize it. Really sucks.

I'd love to see someone build out a djabberd based server with all of wildfire's features, but, you know, not in java. But I'm not the person to do that.
(Reply) (Parent) (Thread)
[User Picture]From: xlerb
2006-04-14 07:54 am (UTC)
It's kinda lame that you can't do challenge-response auth without knowing the password.

It's a shame that SRP isn't more popular; the server's stored information isn't password-equivalent, and neither is anything either side sends to the other, and you get a convenient session key out of it.
(Reply) (Parent) (Thread)