From: Chris Maresca <ckm@xxxxxxxxxxxxxxxxx>
Subject: Re: PAM passthru questions and
SecureID
Message-ID: <4552F189.9060001@xxxxxxxxxxxxxxxxx>
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/
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
