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

[Joe L. <jl...@op...>]

yeah..

regarding LDAP thread safety, etc.. Luke Howard and other people=20
associated with Open-IT have had ideas about this, and thus the project=20=

"kodama" was born to fix issues with OpenLDAP, including referrals.=20
Kodama has stagnated since the various qualified people are too busy and=20=

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=20
api. As to vendor specific ACL's, etc., that is a decision that will be=20=

hard to make. One proposal would be ideal for Zope, bad for Python:=20
Using zope-based ACL primitives (dare I call it that) to handle ACLs and=20=

then simple use SSL-certs (client and server) to authenticate. Kurt and=20=

others keep on saying that OpenLDAP should not be the authentication=20
server, and we should rely upon 3rd party auth (Krb5, etc). The end=20
result is have OpenLDAP use some external auth and some external=20
ACL-mapping to layer upon basic ACL mapping on OpenLDAP. I don't like=20
the sound of this approach as an engineered solution. Instead, work is=20=

still progressing on OpenLDAP's ACL, and again it may be a backend issue=20=

(thats were ACLs/transactions are implemented in OpenLDAP). A true=20
solution could be in kodama, in that kodama-specific API calls could be=20=

used by a python-ldap to systems that can use kodama (more and more=20
development here). Alternatively, native ACL support would be used on=20
others. All of this decided from some config key in the LDAP server=20
itself. Yes, its one big hairy #ifdef. I'm babbling here simply on some=20=

of that ideas thrown out about this. Suffice it to say that it won't be=20=

easily solved, but that creating mature python-objects that contain the=20=

solution will sufficiently hide these details from a higher level app=20
environment like Zope. And at the end of the day, that is all that=20
matters.

As to StartTLS vs ldaps: in pam_ldap and nss_ldap, there is an issue=20
with configuration and compiled versions. Basically, you have=20
configuration files that point to an LDAP server with port, hostname,=20
etc. Pointing to port 636 for all traffic fails for LDAP v2=20
configurations. You will generally find that for large deployed=20
environments, you must support StartTLS and a configuration of port 389=20=

since multiple apps will key off the same "ldap seed" info and only a=20
percentage will be SSL-aware. Also, its always ugly when you have=20
distros/OSes (like Solaris!) that support LDAP v3 but have the SSL=20
libraries as optional installs that are configured at run-time by config=20=

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=F6der 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 =3D> 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.
>
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> http://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>