Re: set_rebind_proc

[<mi...@st...>]

Steffen Ries wrote:
> 
> I recently ran into a problem with a replicated iPlanet directory
> server. My client was setup to write to the slave directory, which
> answered with a REFERRAL. The client was trying to follow the
> referral but could not authenticate with the master directory.

Steffen, I can confirm that you already hit many of the issues 
with following referrals.

> After looking into the code I found that the "set_rebind_proc" method
> has been disabled "until made OpenLDAP2 compatible". Since I need this
> functionality, I have implemented an openLDAP2 compatible version of
> set_rebind_proc.

AFAIR there was no decision made yet in the OpenLDAP project how 
to implement set_rebind_proc. But I have to check recent status.

> The old implementation had an IMHO very bad design flaw: only one
> rebind_proc was allowed for the whole module.

Which is not the only design flaw of set_rebind_proc. It's rather 
flawed by design...

> Since I need to support multiple connections to different directories
> as well, I implemented a solution for this problem.

I have to admit that I'm scared about adding such functionality 
into the C part of python-ldap. I'd like to encourage you to find 
a Python-only solution which is easier to maintain. BTW: That's 
exactly one of the benefits of class ldap.ldapobject.LDAPObject: 
It can be sub-classed for extending its functionality.

> I kept the interface for the callback the same as it was for the old
> implementation, i.e. the callback has to accept an LDAP object and
> return a tuple (DN, CRED, METHOD). 

Please check whether this complies to what's done in OpenLDAP 2 today.

> The second part of the patch is for the python wrapper. I added an
> automatic rebind_procedure, which is installed when you call a version
> of "bind()". This way referrals should normally be transparent to the
> client. I am not sure whether this is a good idea or not (?).

My own investigations of this problem lead to not add any generic 
referral mechanism to python-ldap because one can't find a generic 
way without making too many assumptions. Several issues with 
referrals and - a similar problem - LDAP connection failover.

Connection handling:
An application has to decide whether it follows the referral for a 
single operation (e.g. a single write operations) or drop the 
current LDAP connection completely and switch over to the referred 
server for all following operations. An interesting question in 
e.g. a one master, many slaves scenario.
Another issue is whether there are more operations involved to 
properly establish a new LDAP connection, e.g. calling start_tls_s().

Bind sequence:
Currently most implementations solely use simple bind. But e.g. 
SASL BindRequests are rather more complicated (Kerberos via 
GSS-API, SSL with client certificates). Also the target server 
mentioned in the referral might have other SASL capabilities. 
Another issue is setting the right LDAP protocol version 
(negotiated vs. set by a-priori knowledge).

Security issues:
I have no clue how to model all the different bind mechanisms 
securely. Also one would have to store credentials (not only 
passwords)...

I'd rather like to see a framework which helps the application 
developer to implement generic exception handlers for e.g. 
ldap.SERVER_DOWN or ldap.REFERRAL and decide what to do in his/her 
specific environment.

We could store the last operation tried in a class attribute by 
just extending LDAPObject._ldap_call(). Hmm, adding the parameters 
of the LDAP operation which raised a LDAPError exception to the 
LDAPError exception instance itself would be really nice...

Ciao, Michael.