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

Re: SASL support in back-ldap & back-meta (ITS#3022)



ando@sys-net.it wrote:

>quanah@stanford.edu wrote:
>
>  
>
>>--On Tuesday, June 15, 2004 7:54 AM +0000 Pierangelo Masarati 
>><openldap-its@OpenLDAP.org> wrote:
>>
>> 
>>
>>    
>>
>>>back-ldap now supports identity assertion via proxyAuthz and/or native
>>>SASL authz; the proxy must be configured with appropriate idassert-*
>>>parameters to optionally use SASL for binding and identity assertion (or
>>>authorization).
>>>
>>>There are no plans, currently, to do the same for back-meta.
>>>   
>>>
>>>      
>>>
>>Thanks! I'll have to give this a whirl... I take it this won't actually 
>>show up in releases until 2.3?
>> 
>>
>>    
>>
>just committed a test about this; from HEAD/tests/, ./run test028
>this simply tests the idassert feature; to use SASL authc/authz
>on one of the two ldap databases in the tests you need to (compile
>with SASL, of course, and) manually set the evironment variable
>SLAPD_USE_SASL=yes; it uses DIGEST-MD5 because it's the
>only I've played with, to use GSSAPI you'll need to play with
>data/slapd-idassert.conf; I'll make this work thru the env as well.
>
>Note that I didn't rebuild configure after changing configure.in
>because I use different versions of autotools, so, until it gets
>regenerated, you'll need to run autoconf yourself, to get SASL
>automatic detection set up; another temporary solution is to
>manually add AC_WITH_SASL=yes in tests/run
>  
>
The test is fixed right now.  Use SLAPD_USE_SASL={yes|<mech>}
to allow extra SASL tests.  I've checked it with simple auth and SASL
CRAM-MD5 and DIGEST-MD5.  With CRAM-MD5, the native SASL
authz doesn't work, i.e. the proxy remains bound with the administrative
identity instead of authz'ing as the initial user.  The code of the proxy
works as expected (checked step by step with gdb), it's the SASL that
doesn't perform the authz even if instructed to do so.  With DIGEST-MD5
everything works as expected.  The test doesn't fail in either case, because
the administrative identity has the same permissions of the initial user.
The test might be modified in the future to address this issue.

p.



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