1back-proxy 2 3A proxy that handles a pool of URI associated to a unique suffix. 4Each request is spread over the different URIs and results are 5masqueraded to appear as coming from a unique server. 6 7Suppose a company has two branches, whose existing DS have URIs 8 9"ldap://ldap.branch1.com/o=Branch 1, c=US" 10"ldap://ldap.branch2.it/o=Branch 2, c=IT" 11 12and it wants to propose to the outer world as a unique URI 13 14"ldap://ldap.company.net/dc=company, dc=net" 15 16It could do some rewriting to map everything that comes in with a base DN 17of "o=Branch 1, dc=company, dc=net" as the URI of the Branch 1, and 18everything that comes in with a base DN of "o=Branch 2, dc=company, dc=net" 19as the URI of Branch 2, and by rewriting all the DNs back to the new, uniform 20base. Everything that comes in with a base DN of "dc=company, dc=net" should 21be handled locally and propagated to the two branch URIs if a subtree 22(or at least onelevel) search is required. 23 24Operations: 25 26- bind 27- unbind 28- search 29- compare 30- add 31- modify 32- modrdn 33- delete 34- abandon 35 36The input of each operation may be related to: 37 38 exact DN exact parent ancestor 39------------------------------------------------------------- 40bind x 41unbind 42search x x x 43compare x 44add x 45modify x 46modrdn x 47delete x 48abandon 49 50The backend must rely on a DN fetching mechanism. Each operation requires 51to determine as early as possible which URI will be able to satisfy it. 52Apart from searches, which by definition are usually allowed to return 53multiple results, and apart from unbind and abandon, which do not return any 54result, all the remaining operations require the related entry to be unique. 55 56A major problem isposed by the uniqueness of the DNs. As far as the suffixes 57are masqueraded by a common suffix, the DNs are no longer guaranteed to be 58unique. This backend relies on the assumption that the uniqueness of the 59DNs is guaranteed. 60 61Two layers of depth in DN fetching are envisaged. 62The first layer is provided by a backend-side cache made of previously 63retrieved entries. The cache relates each RDN (i.e. the DN apart from the 64common suffix) to the pool of URIs that are expected to contain a subset 65of its children. 66 67The second layer is provided by a fetching function that spawns a search for 68each URI in the pool determined by the cache if the correct URI has not been 69directly determined. 70 71Note that, as the remote servers may have been updated by some direct 72operation, this mechanism does not guarantee the uniqueness of the result. 73So write operations will require to skip the cache search and to perform 74the exaustive search of all the URIs unless some hint mechanism is provided 75to the backend (e.g. a server is read-only). 76 77Again, the lag between the fetching of the required DN and the actual 78read/write may result in a failure; however, this applies to any LDAP 79operation AFAIK. 80 81- bind 82if updates are to be strictly honored, a bind operation is performed against 83each URI; otherwise, it is performed against the URIs resulting from a 84cache-level DN fetch. 85 86- unbind 87nothing to say; all the open handles related to the connection are reset. 88 89- search 90if updates are to be strictly honored, a search operation is performed agaist 91each URI. Note that this needs be performed also when the backend suffix 92is used as base. In case the base is stricter, the URI pool may be restricted 93by performing a cache DN fetch of the base first. 94 95- compare 96the same applies to the compare DN. 97 98- add 99this operation is delicate. Unless the DN up to the top-level part excluded 100can be uniquely associated to a URI, and unless its uniqueness can be trusted, 101no add operation should be allowed. 102