[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: ldap_sasl_interactive_bind_s
On 29 May 2007, at 23:33, Howard Chu wrote:
Quanah Gibson-Mount wrote:
I'm working on a patch to add LDAP SASL support to Postfix 2.4 (I
made one for 2.2/2.3 a long time ago), and this time I want it to
be accepted upstream, so I'm working on what they feel the issues
are.
Right now, they
(a) always want LDAP_SASL_QUIET enabled (makes perfect sense to me)
and
(b) want the SASL mechanism to be a list of mechanisms the client
supports, that should be tried when connecting to the server.
I think (b) is rather non-sensical, given the configurations are
rather different between things like DIGEST-MD5, EXTERNAL, and
GSSAPI just to start, but...
I assume to support this I should use the
ldap_sasl_interactive_bind_s function, which takes as a parameter
a list of mechanisms, if I'm reading it right. The question to me
comes up with mixing LDAP_SASL_QUIET in, because part of the
routine involved with multiple mechansisms seems to want
interaction with the client.
My assumption is that if I use ldap_sasl_interactive_bind_s, with
LDAP_SASL_QUIET, and pass in a list of mechanisms, the client will
just use the first mechanism in its list. Is that correct?
No. The list of mechanisms is passed directly to the SASL library.
The SASL library will choose a mechanism from that list based on
the security properties that were set. And obviously, since it is a
separate library that has no knowledge of the LDAP_SASL_ flags,
LDAP_SASL_QUIET doesn't affect it at all.
I've done something similar to this with other SASL clients. I assume
that what you (they?) want is to be able to provide a list along the
lines of 'try GSSAPI, then if that fails, try DIGEST-MD5', etc. You
can drive Cyrus SASL in this way, but I suspect you need a closer
relationship to the SASL code than ldap_sasl_bind_interactive_s gives
you. Roughly, what works is to take the list of mechanisms that the
server gives you, and start a loop. Call into the SASL library with
this list, and do the SASL handshake as normal. If it fails at any
point, ask it what mechanism just failed, and remove it from your
list of permitted mechanisms, and go round again. You're done when
you've either run out of permitted mechanisms, or the authentication
succeeds. This model means that you can try GSSAPI first, and then
fall back to password based mechanisms when that fails, without
having to involve the user in that process.
Cheers,
Simon.