--On Saturday, June 19, 2004 9:19 AM -0700 "Kurt D. Zeilenga"
<Kurt@OpenLDAP.org> wrote:
I guessed something like that, and I was going to look for a means to
detect what mechs support it, because the idassert code currently
assumes that when configured to use SASL method authz will be done
natively by SASL.
I suggest you just hardcode it for DIGEST-MD5 (and skip if
not available). Maybe support PLAIN as well (but you'll
have to configure both client & server to allow it without
TLS.
Err, I specifically requested this feature, specifically for SASL/GSSAPI.
So hard coding this for DIGEST-MD5 again makes back-ldap unusable for me.
Quanah,
the only hardcoding, at the moment, is in deciding what mechs are able to
natively perform authorization. I guess GSSAPI can, so I'll hardcode that
too. Right no all you need to do is configure the idassert part with
idassert-method sasl mech=GSSAPI authz=native [...]
I would really appreciate that, accoding to your priorities, you test this
with GSSAPI and report about its behavior. I don't think I'll ever get
into the headache of setting up a GSSAPI testing environment since we're
not using it right now.
I can surely provide all the help you need in deigning the test
configuration; maybe we should better do something different from the
current test, because that is essentially a tenttive of a unit test, with
some plausible combinations of parameters and scenarios; to assess the
behavior with GSSAPI we may want to start with a simpler scenario, i.e. a
local database for auth, a remote database for data provisioning and a
proxy that binds and authzes the local identity to the remote server. If
we cn make it work with GSSAPI for the id assertion, and simple and GSSAPI
for the local bind, it's fine.