[Date Prev][Date Next]
Re: commit: ldap/tests/scripts test028-idassert conf.sh
- To: email@example.com
- Subject: Re: commit: ldap/tests/scripts test028-idassert conf.sh
- From: Quanah Gibson-Mount <firstname.lastname@example.org>
- Date: Sun, 13 Mar 2005 14:03:37 -0800
- Cc: OpenLDAP Commit <openldap-devel@OpenLDAP.org>
- Content-disposition: inline
- In-reply-to: <email@example.com>
- References: <200406190805.i5J8576F003857@cantor.openldap.org> <40D43C50.firstname.lastname@example.org> <email@example.com> <40D45E42.firstname.lastname@example.org> <email@example.com> <B8218B5CF854F9B3033555E2@cadabra-dsl.stanford.edu> <firstname.lastname@example.org>
--On Saturday, June 19, 2004 9:01 PM +0200 Pierangelo Masarati
--On Saturday, June 19, 2004 9:19 AM -0700 "Kurt D. Zeilenga"
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
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.
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?
Principal Software Developer
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