git.sur5r.net Git - openldap/blob - servers/slapd/back-ldap/TODO.proxy

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