> From: Chris Maresca <ckm at olliancegroup.com> > Subject: Re: PAM passthru questions and > SecureID > Message-ID: <4552F189.9060001 at olliancegroup.com> > 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.... Rich isn't recommending the use of saslauthd, and developing a SASL plugin for whatever purpose is pretty easy. > 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. Agreed, saslauthd is junk. >> > 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. You've identified a shortcoming but you're going about fixing it the wrong way. Rich is trying to point you down the proper track; the right way is to get the desired SASL plugin written. >> > 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.... <shameless plug>I work with both the OpenLDAP and Cyrus SASL Projects; my company Symas Corp. can easily develop what's needed here and submit it to Cyrus for you. Once you've got the requirements spelled out, come talk to us.</shameless plug> -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/
