This doesn't belong on the -devel list.
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.
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.
--On Wednesday, May 30, 2007 8:50 AM +0100 Simon Wilkinson simon@sxw.org.uk wrote:
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.
Hm, do you have an example of this available? ;)
--Quanah
-- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-software@openldap.org
-
Howard Chu -
Quanah Gibson-Mount -
Simon Wilkinson