1 Copyright 1998-2001 The OpenLDAP Foundation, All Rights Reserved.
2 COPYING RESTRICTIONS APPLY, see COPYRIGHT file
4 Copyright 2001, Pierangelo Masarati, All rights reserved. <ando@sys-net.it>
10 This is a brief introduction to the core functionalities of back-meta.
16 Back-meta implements a backend for OpenLDAP's slapd. It performs basic
17 LDAP proxying with respect to a set of remote LDAP servers, called
18 "targets". The information contained in these servers can be presented
19 as belonging to a single Directory Information Tree (DIT).
21 A basic knowledge of the functionality of back-ldap is recommended.
22 This backend has been designed as an enhancement of back-ldap.
23 The two backends share many features (actually they also share portions
24 of code). While back-ldap is intended to proxy operations directed
25 to a single server, back-meta is mainly intended for proxying
26 of multiple servers and possibly naming context masquerading.
27 These features, although useful in many scenarios, may result in
28 excessive overhead for some applications, so its use should be
31 In the examples section, some typical scenarios will be discussed.
35 - Common configuration directives
37 The backend uses most of the common configuration directives. Its
38 configuration block starts with the "database" directive:
42 At least a "suffix" directive is required.
44 Note: as with back-ldap, operational attributes related to entry
45 creation/modification should not be used, as they would be passed
46 to the target servers, generating an error. Moreover, it makes
47 little sense to use such attributes in proxying, as the proxy
48 server doesn't actually store data, so it should have no knowledge
49 of such attributes. While code to strip the modification attributes
50 has been put in place (and #ifdef'd), it implies unmotivated overhead.
51 So it is strongly recommended to set
55 for every back-ldap/back-meta backend.
59 - Special configuration directives
61 Target configuration starts with the "uri" directive. All the
62 configuration directives that are not specific to targets should
63 be defined first for clarity, including those that are common to
64 all backends. They are:
68 This directive forces the backend to reject all those operations
69 that must resolve to a single target in case none or multiple
70 targets are selected. They include: add, delete, modify, modrdn;
71 compare is not included, as well as bind since, as they don't
72 alter entries, in case of multiple matches an attempt is made
73 to perform the operation on any candidate target, with the
74 constraint that at most on must succeed. This directive can also
75 be used when processing targets to mark a specific target as default.
77 dncache-ttl {forever|disabled|<ttl>}
79 This directive sets the time-to-live of the dn cache. This caches
80 the target that holds a given dn to speed up target selection
81 in case multiple targets would result from an uncached search;
82 forever means cache never expires; disabled means no dn caching;
83 otherwise a valid ( > 0 ) ttl in seconds is required.
87 - Target specification
89 Target specification starts with a "uri" directive:
91 uri <protocol>://[<host>[:<port>]]/<naming context>
93 The "server" directive that was allowed in back-ldap (although deprecated)
94 has been discarded in back-meta. The <protocol> part can be anything
95 ldap_initialize(3) accepts ({ldap|ldaps|ldapi} and variants); <host>
96 and <port> may be omitted, defaulting to whatever is set in
97 /etc/ldap.conf (correct me!?!).
98 The <naming context> part is mandatory. It must end with one of the
99 naming contexts defined for the backend, e.g.:
101 suffix "dc=foo,dc=com"
102 uri "ldap://x.foo.com/dc=x,dc=foo,dc=com"
104 The <naming context> part doesn't need to be unique across the targets;
105 it may also match one of the values of the "suffix" directive.
107 default-target [<target>]
109 the "default-target" directive can also be used during target
110 specification. With no arguments it marks the current target as
111 the default. The optional number marks target <target> as the
112 default one, starting from 1. Target <target> must be defined.
114 binddn <administrative dn for ac purposes>
116 This directive, as in back-ldap, allows to define the dn that is
117 used to query the target server for acl checking; it should have
118 read access on the target server to attributes used on the proxy
119 for acl checking. There is no risk of giving away such values;
120 they are only used to check permissions.
122 bindpw <plaintext password for ac purposes>
124 This directive sets the password for acl checking in conjunction
125 with the above mentioned "binddn" directive.
129 suffixmassage <virtual naming context> <real naming context>
131 All the directives starting with "rewrite" refer to the rewrite engine
132 that has been added to slapd. The "suffixmassage" directive was
133 introduced in back-ldap to allow suffix massaging while proxying.
134 It has been obsoleted by the rewriting tools. However, both for
135 backward compatibility and for ease of configuration when simple
136 suffix massage is required, it has been preserved. It wraps the
137 basic rewriting instructions that perform suffix massaging.
139 Note: this also fixes a flaw in suffix massaging, which operated
140 on (case insensitive) DNs instead of normalized DNs,
141 so "dc=foo, dc=com" would not match "dc=foo,dc=com".
143 See the "rewrite" section.
145 map {objectClass|attribute} {<source>|*} [<dest>|*]
147 objectClass/attribute mapping stuff. This has been inherited from
148 the work made by Mark Valence on the back-ldap backend.
149 See the mapping section.
155 A powerful (and in some sense dangerous) rewrite engine has been added
156 to both back-ldap and back-meta. While the former can gain limited
157 beneficial effects from rewriting stuff, the latter can become
158 an amazingly powerful tool.
160 Consider a couple of scenarios first.
162 1) Two directory servers share two levels of naming context;
163 say "dc=a,dc=foo,dc=com" and "dc=b,dc=foo,dc=com". Then, an
164 unambiguous back-meta can be configured as:
167 suffix "dc=foo,dc=com"
169 uri "ldap://a.foo.com/dc=a,dc=foo,dc=com"
171 uri "ldap://b.foo.com/dc=b,dc=foo,dc=com"
173 Operations directed to a specific target can be easily resolved
174 because there are no ambiguities. The only operation that may
175 resolve to multiple targets is a search with base "dc=foo,dc=com"
176 and scope at least "one", which results in spawning two searches
179 2a) Two directory servers don't share any portion of naming context,
180 but they'd present as a single DIT. [Caveat: uniqueness of
181 (massaged) entries among the two servers is assumed; integrity
182 checks risk to incurr in excessive overhead and have not been implemented.]
183 Say we have "dc=bar,dc=org" and "o=Foo,c=US", and we'd like them to
184 appear as branches of "dc=foo,dc=com", say "dc=a,dc=foo,dc=com"
185 and "dc=b,dc=foo,dc=com". Then we need to configure our back-meta as:
188 suffix "dc=foo,dc=com"
190 uri "ldap://a.bar.com/dc=a,dc=foo,dc=com"
191 suffixmassage "dc=a,dc=foo,dc=com" "dc=bar,dc=org"
193 uri "ldap://b.foo.com/dc=b,dc=foo,dc=com"
194 suffixmassage "dc=b,dc=foo,dc=com" "o=Foo,c=US"
196 Again, operations can be resolved without ambiguity, although
197 some rewriting is required. Notice that the virtual naming context
198 of each target is a branch of the database's naming context; it
199 is rewritten back and forth when operations are performed towards
200 the target servers. What "back and forth" means will be clarified
203 When a search with base "dc=foo,dc=com" is attempted, if the
204 scope is "base" it fails with "no such object"; in fact, the
205 common root of the two targets (prior to massaging) does not
206 exist. If the scope is "one", both targets are contacted with
207 the base replaced by each target's base; the scope is derated
208 to "base". In general, a scope "one" search is honored,
209 and the scope is derated, only when the incoming base is
210 at most one level lower of a target's naming context (prior
212 Finally, if the scope is "sub" the incoming base is replaced
213 by each target's unmassaged naming context, and the scope
216 2b) Consider the above reported scenario with the two servers
217 sharing the same naming context:
220 suffix "dc=foo,dc=com"
222 uri "ldap://a.bar.com/dc=foo,dc=com"
223 suffixmassage "dc=foo,dc=com" "dc=bar,dc=org"
225 uri "ldap://b.foo.com/dc=foo,dc=com"
226 suffixmassage "dc=foo,dc=com" "o=Foo,c=US"
228 All the previous considerations hold, except that now there is
229 no way to unambiguously resolve a dn. In this case, all the
230 operations that require an unambiguous target selection will
231 fail unless the dn is already cached or a default target has
238 This part of the document is being prepared. At present you may consult
239 the RATIONALE in libraries/librewrite.
243 - Objectclass/attribute mapping
245 This part of the document is being prepared. At present you may stick with
247 http://www.openldap.org/lists/openldap-devel/200102/msg00006.html
252 Note on ACLs: at present you may add whatever ACL rule you desire
253 to back-meta (as well as to back-ldap). However, the meaning of an ACL
254 on a proxy may require some considerations. Two philosophies may be
257 a) the remote server dictates the permissions; the proxy simply passes
258 back what it gets from the remote server.
260 b) the remote server unveils "everything"; the proxy is responsible
261 for protecting data from unauthorized access.
263 Of course the latter sounds unreasonable, but it is not. It is possible
264 to imagine scenarios in which a remote host discloses data that can
265 be considered "public" inside an intranet, and a proxy that connects it
266 to the internet may impose additional constraints. To this purpose, the
267 proxy should be able to comply with all the ACL matching criteria that
268 the server supports. This has been achieved with regard to all the
269 criteria supported by slapd except a special subtle case (please drop
270 me a note if you can find other exceptions: <ando@openldap.org>).
273 access to dn="<dn>" attr=<attr>
274 by dnattr=<dnattr> read
277 cannot be matched IFF:
278 - the attribute that is being requested, <attr>, is NOT <dnattr>, and
279 - the attribute that determines membership, <dnattr>, has not
280 been requested (e.g. in a search)
282 In fact this ACL is resolved by slapd using the portion of entry it retrieved
283 from the remote server without requiring any further intervention of the
284 backend, so, if the <dnattr> attribute has not been fetched, the match
285 cannot be assessed because the attribute is not present, not because
286 no value matches the requirement!
289 Note on ACLS and attribute mapping: ACLs are applied to the mapped
290 attributes; for instance, if the attribute locally known as "foo"
291 is mapped to "bar" on a remote server, then local ACLs apply to
292 attribute "foo" and are totally unaware of its remote name. The
293 remote server will check permissions for "bar", and the local server
294 will possibly enforce additional restrictions to "foo".