[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: commit: ldap/tests/scripts test028-idassert conf.sh

> --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.


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.

Ciao, Ando.

Pierangelo Masarati

    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497