mirror of
https://git.openldap.org/openldap/openldap.git
synced 2024-12-21 03:10:25 +08:00
102 lines
3.6 KiB
Plaintext
102 lines
3.6 KiB
Plaintext
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 exaustive 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 agaist
|
|
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.
|