- The (XMPP) service does not have to be reconfigured for different environments (e.g. passwd files vs kerberos vs ldap),
- No separate password database.
My concern re: #1 is that there is some interest in running an Instant Messaging (IM) service at work but little support for getting a kerberized service. The server (Jive Wildfire) support for it is tentative at best and client support is none (e.g. ticketed authentication) so why bother? I'd have to setup key entries for the service to talk to the KDC and basically do a lot of work whereas the Pluggable Authentication Module (PAM) system is there and ready. Heck, even if the server-side support was better, the complete lack of GSSAPI/Kerberos support on the client side is a killer.
So on to #2 which is the main reason for doing any of this at all. Managing seperate password databases means system users have to have a login and password for every service and manage their passwords seperately. Since this doesn't happen (with normal users), everyone just uses the same password for everything and they use the same password for years and years. It's bad enough with the sys admins doing the same thing for core services, but that's a whole other issue.
Anyhow, I had initially setup Jive Wildfire (then Jive Messenger) to authenticate directly against my LDAP directory specifically to avoid the problems with #2. It worked well. But now faced with managing an IM server for work, I have the same two problems. Maintaining a separate password database is going to mean zero user buy-in but if I can say "just use your IRMACS password" then it won't be a problem. So that gets us back to how to setup the auth to integrate with the Kerberos system. The answer is "I dunno" or PAM.
So, PAM, you little bastard, what's the deal? It turns out Jive Wildfire doesn't have PAM support either natively or as a proper plugin (e.g. loadable at runtime) so what we need is this Java module called Shaj. Put the Java library, the .jar file, and the platform-specific library, the .so file, into wildfire/lib. Then configure Jive to use "Native Authentication":
<provider>
<auth>
<className>org.jivesoftware.wildfire.auth.NativeAuthProvider</className>
</auth>
<user>
<className>org.jivesoftware.wildfire.user.NativeUserProvider</className>
</user>
</provider>
And voila! Right? WRONG! I couldn't login, my client kept crashing, this "Shaj" thing was screwed. I went back and forth, back and forth, and just to get to the point where I knew what to do (above) but it ust didn't work. Something was odd since I was finally able to login to the admin interface but still nothing on the client.
It turns out that, naturally, after having been flailing around in the dark in the first place, my client had finally bit the dust. Something just got fubar between the removing and adding accounts and the server going up and down and up and down... After I stomped all my kopete config files, it worked great! Auth against PAM! Beauty!
So now I still have to test one last feature... Can I change my system password through my IM client? Does that just change my IM password (e.g. is it stored by Wildfire) or does it change my system password? Does it work at all? What about if I change my system password, is that reflected immediately in the IM login?
All I know is that "it should work (tm)"
No comments:
Post a Comment