[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openldap-devel
Subject:    Re: commit: ldap/tests/scripts test028-idassert conf.sh
From:       Quanah Gibson-Mount <quanah () stanford ! edu>
Date:       2004-06-26 8:34:30
Message-ID: 6E8909BE4F85AED1F2462A7D () cadabra-dsl ! stanford ! edu
[Download RAW message or body]



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

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

Ando,

Once the syncRepl stuff Jong is looking at is fixed, I'll look at this 
next. :)

--Quanah

--
Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
[prev in list] [next in list] [prev in thread] [next in thread]