From 5ea77a75dd2d2158401331879f3c8f47940a732c Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Sun, 7 Apr 2024 18:35:32 +0200 Subject: Adding upstream version 2.5.13+dfsg. Signed-off-by: Daniel Baumann --- servers/slapd/back-ldap/TODO.proxy | 101 +++++++++++++++++++++++++++++++++++++ 1 file changed, 101 insertions(+) create mode 100644 servers/slapd/back-ldap/TODO.proxy (limited to 'servers/slapd/back-ldap/TODO.proxy') diff --git a/servers/slapd/back-ldap/TODO.proxy b/servers/slapd/back-ldap/TODO.proxy new file mode 100644 index 0000000..01406c5 --- /dev/null +++ b/servers/slapd/back-ldap/TODO.proxy @@ -0,0 +1,101 @@ +back-proxy + +A proxy that handles a pool of URI associated to a unique suffix. +Each request is spread over the different URIs and results are +masqueraded to appear as coming from a unique server. + +Suppose a company has two branches, whose existing DS have URIs + +"ldap://ldap.branch1.com/o=Branch 1, c=US" +"ldap://ldap.branch2.it/o=Branch 2, c=IT" + +and it wants to propose to the outer world as a unique URI + +"ldap://ldap.company.net/dc=company, dc=net" + +It could do some rewriting to map everything that comes in with a base DN +of "o=Branch 1, dc=company, dc=net" as the URI of the Branch 1, and +everything that comes in with a base DN of "o=Branch 2, dc=company, dc=net" +as the URI of Branch 2, and by rewriting all the DNs back to the new, uniform +base. Everything that comes in with a base DN of "dc=company, dc=net" should +be handled locally and propagated to the two branch URIs if a subtree +(or at least onelevel) search is required. + +Operations: + +- bind +- unbind +- search +- compare +- add +- modify +- modrdn +- delete +- abandon + +The input of each operation may be related to: + + exact DN exact parent ancestor +------------------------------------------------------------- +bind x +unbind +search x x x +compare x +add x +modify x +modrdn x +delete x +abandon + +The backend must rely on a DN fetching mechanism. Each operation requires +to determine as early as possible which URI will be able to satisfy it. +Apart from searches, which by definition are usually allowed to return +multiple results, and apart from unbind and abandon, which do not return any +result, all the remaining operations require the related entry to be unique. + +A major problem isposed by the uniqueness of the DNs. As far as the suffixes +are masqueraded by a common suffix, the DNs are no longer guaranteed to be +unique. This backend relies on the assumption that the uniqueness of the +DNs is guaranteed. + +Two layers of depth in DN fetching are envisaged. +The first layer is provided by a backend-side cache made of previously +retrieved entries. The cache relates each RDN (i.e. the DN apart from the +common suffix) to the pool of URIs that are expected to contain a subset +of its children. + +The second layer is provided by a fetching function that spawns a search for +each URI in the pool determined by the cache if the correct URI has not been +directly determined. + +Note that, as the remote servers may have been updated by some direct +operation, this mechanism does not guarantee the uniqueness of the result. +So write operations will require to skip the cache search and to perform +the exhaustive search of all the URIs unless some hint mechanism is provided +to the backend (e.g. a server is read-only). + +Again, the lag between the fetching of the required DN and the actual +read/write may result in a failure; however, this applies to any LDAP +operation AFAIK. + +- bind +if updates are to be strictly honored, a bind operation is performed against +each URI; otherwise, it is performed against the URIs resulting from a +cache-level DN fetch. + +- unbind +nothing to say; all the open handles related to the connection are reset. + +- search +if updates are to be strictly honored, a search operation is performed against +each URI. Note that this needs be performed also when the backend suffix +is used as base. In case the base is stricter, the URI pool may be restricted +by performing a cache DN fetch of the base first. + +- compare +the same applies to the compare DN. + +- add +this operation is delicate. Unless the DN up to the top-level part excluded +can be uniquely associated to a URI, and unless its uniqueness can be trusted, +no add operation should be allowed. -- cgit v1.2.3