ANNC and query: ldapmodule-1.10a3-patched RPMs available

[Joe Little]

yeah..

regarding LDAP thread safety, etc.. Luke Howard and other people 
associated with Open-IT have had ideas about this, and thus the project 
"kodama" was born to fix issues with OpenLDAP, including referrals. 
Kodama has stagnated since the various qualified people are too busy and 
I'm not up to par to handle that bit.

Some things can/will need to be done in python instead of the c-level 
api. As to vendor specific ACL's, etc., that is a decision that will be 
hard to make. One proposal would be ideal for Zope, bad for Python: 
Using zope-based ACL primitives (dare I call it that) to handle ACLs and 
then simple use SSL-certs (client and server) to authenticate. Kurt and 
others keep on saying that OpenLDAP should not be the authentication 
server, and we should rely upon 3rd party auth (Krb5, etc). The end 
result is have OpenLDAP use some external auth and some external 
ACL-mapping to layer upon basic ACL mapping on OpenLDAP. I don't like 
the sound of this approach as an engineered solution. Instead, work is 
still progressing on OpenLDAP's ACL, and again it may be a backend issue 
(thats were ACLs/transactions are implemented in OpenLDAP). A true 
solution could be in kodama, in that kodama-specific API calls could be 
used by a python-ldap to systems that can use kodama (more and more 
development here). Alternatively, native ACL support would be used on 
others. All of this decided from some config key in the LDAP server 
itself. Yes, its one big hairy #ifdef. I'm babbling here simply on some 
of that ideas thrown out about this. Suffice it to say that it won't be 
easily solved, but that creating mature python-objects that contain the 
solution will sufficiently hide these details from a higher level app 
environment like Zope. And at the end of the day, that is all that 
matters.

As to StartTLS vs ldaps: in pam_ldap and nss_ldap, there is an issue 
with configuration and compiled versions. Basically, you have 
configuration files that point to an LDAP server with port, hostname, 
etc. Pointing to port 636 for all traffic fails for LDAP v2 
configurations. You will generally find that for large deployed 
environments, you must support StartTLS and a configuration of port 389 
since multiple apps will key off the same "ldap seed" info and only a 
percentage will be SSL-aware. Also, its always ugly when you have 
distros/OSes (like Solaris!) that support LDAP v3 but have the SSL 
libraries as optional installs that are configured at run-time by config 
files, etc.

In the end, StartTLS and port 389 is the way to go...

On Wednesday, May 9, 2001, at 09:25  AM, Michael Ströder wrote:

> Joe Little wrote:
>>
>> I'm not complaining..
>
> Joe, since you are really contributing code be assured that I did
> not point to you.
>
>> we need specifically to support v3 schema,
>
> Could be done in higher-level Python modules. (Not trivial though.)
> Not sure if you won't have to fiddle with BER-encoded data
> (implementing syntax matching).
>
>> OpenLDAP v2 ACLs,
>
> Currently this whole ACL thing is vendor-specific => you would have
> to write a specific module for each LDAP server. Finding a good
> abstraction level would be required. See also "Access Control Model
> for LDAP" on http://www.ietf.org/html.charters/ldapext-charter.html
> for an attempt to define a standard. There's no need for a modified
> C extension module. You could also implement this in Python.
>
>> StartTLS,
>
> Or LDAP over SSL (ldaps://..). IMHO STARTTLS is not widely
> implemented up to now.
>
> Let me add two things.
>
> Thread-safety/reentrant: Would require to go with the Mozilla SDK or
> use ldap_r of OpenLDAP 2.0.x (experimental, see my other posting
> with Kurt's not about it).
>
> Proper handling of referrals / search continuations: Konstantin's
> patch already provides this but there are sometimes strange LDAP
> referral URLs returned. Might be a bug of the OpenLDAP 2.0.x libs.
>
> Ciao, Michael.
>
>