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

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

--On Saturday, June 19, 2004 9:01 PM +0200 Pierangelo Masarati <ando@sys-net.it> wrote:

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

Hi Ando,

I've finally gotten to the point where I would like to start testing back-ldap with SASL.

One of my initial concerns in reading the man page in 2.3.1 alpha is that the acl-authcDN that is used to query the ACL's from the target server appears to only support simple binds. In Stanford's environment, we don't support simple binds at all, which means I have no way of letting back-ldap (or back-meta) query the target server for the ACL information.

However, I understand my reading of this may be entirely incorrect, and that there is a way to set the acl-authcDN and combine that with the idassert feature so that a SASL mech can be used to do the bind to the target server for ACL information. Can you let me know if I'm incorrect in my assumption on the simple bind?



Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

"These censorship operations against schools and libraries are stronger
than ever in the present religio-political climate. They often focus on
fantasy and sf books, which foster that deadly enemy to bigotry and blind
faith, the imagination." -- Ursula K. Le Guin