Richard Megginson wrote: > But this is what SASL was designed to do - isolate applications from the > authentication implementation details. Ideally, it would go like this: > LDAP -> SASL -> sasl auth server plugin -> auth server Yes, but there are a very limited number of SASL plugins, basically NTLM, Kerberos, GSS and SecurID. Non-plugin auths are done through the 'external' method, which uses saslauthd, a hack as it actually requires accounts to be created to work properly. Saslauthd also only handles passwords in plain text, communicates over an unsecure socket, runs as root and is single-threaded.... so the chain winds up being: LDAP -> SASL -> plaintext sockect connection -> saslauthd -> sasl-auth method -> auth server SASL is quite good, but saslauthd is not so great. It was never actually intended for this, but as a proxy to deal with apps that did not have SASL natively. > Then you could just to an LDAP SASL BIND with a mechanism like > "SASL-SECURID" or something like that, and pass in whatever credentials > are required by the auth server in the sasl credentials field. I don't disagree, but none of the vendors are providing this capability. The real world and the ideal situation are not really lining up.... > However, if it is more difficult to take the SASL plugin approach, or > the vendors are just not going to make this happen, then we should > figure out how to extend the PAM passthru plugin to handle cases like this. That's the way it is right now, so yeah, extending PAM passthru would be good. SASL may be the long term future, but right now, it's not deployable except for one vendor's mechanism. > Would you be able to write up something for the Fedora DS wiki, like an > informal software requirements doc? Sure, I can do that. I'd even offer to look at some code, but it's been years since I authored anything in C and I know nothing of the Fedora DS code.... Chris. -- Chris Maresca Founding Partner Olliance Group, LLC www.olliancegroup.com +1.650.331.1770 x201
