LDAP list digest wrote:
From: Adam Tauno Williams <[EMAIL PROTECTED]> Date: Tue, 18 Oct 2005 10:00:00 -0400 X-Message-Number: 2 > As I am aware, there are two ways of handling the referrals > available. As per the 1st one, the LDAP server returns the referral > information to the client and then the client contacts the > referred server on its own. This is standardized in the LDAP > specifications also.
Yep.
> As per the 2nd one, the LDAP server itself contacts the other LDAP > server(where the data is located) and returns the response to the > client. This is called as 'referral chaining'. I would like to know > why 'referral chaining' is not yet standardized. Was it because of > the later introduction of the ''referral chaining' concept after > the LDAP standard formulation was completed, or because of some > technical reasons?
This is really more of a DSA feature than a 'part of LDAP'. The reason that it isn't standardized is that - (1) you don't always want to follow referralss, for administrative purposes for instance and (2) referrals can be a security problem if client A talks to server B and then client As credentials, query, etc... get shunted over to server C. Should the client trust server C? This decision (IMHO) belongs squarely with the client; unless local administrators have taken the trouble to weave some magick to glue two or more servers together.
You're hinting at the root of the problem, but not quite there. LDAP was originally designed only to be a client-to-server protocol for accessing X.500 directory information. In the X.500 system, chaining is a server-to-server function, so it was outside the scope of the LDAP specification. Later LDAP started being used as a standalone system that no longer needed to talk to real X.500 servers. But unfortunately, since LDAP was only designed for talking to one server, there still was no provision for server-to-server communication, and this aspect of the directory system design is still lacking in LDAP today.
The fact that LDAP has no language for even discussing the concepts of transitive trust or delegation of authority leaves this whole area a big mess that individual LDAP implementations try their best to mitigate. But the basic problem is that LDAP is a lobotomized protocol to begin with. While information has a tendency to live in multiple places, and the X.500 directory system was designed to allow directory servers to reside in multiple places and all cooperate together as a cohesive whole, LDAP has none of that intelligence. This is why crossing server boundaries in LDAP is inherently clunky and insecure. Draft specifications have been written to add extensions to LDAP to try to address these shortcomings, but IMO they are unworkable (and they mostly appear to be expired now anyway). One problem is that when managing a distributed information network, servers actually do need to know unambiguously whether they are talking to a peer server or another client. Since LDAP Controls and Extended Operations designed to facilitate server-to-server operation can also be validly generated by regular clients, the problem of encapsulating client data and segregating it from server-to-server progress information is basically unsolvable in LDAP.
-- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/ --- You are currently subscribed to [email protected] as: [EMAIL PROTECTED] To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the SUBJECT of the message.
