1
.TH SLAPD-RELAY 5 "RELEASEDATE" "OpenLDAP LDVERSION"
3
slapd-relay \- relay backend to slapd
7
The primary purpose of this
9
backend is to map a naming context defined in a database
12
instance into a virtual naming context, with attributeType
13
and objectClass manipulation, if required.
18
This backend and the above mentioned overlay are experimental.
22
directives apply to the relay backend database.
23
That is, they must follow a "database relay" line and come before any
24
subsequent "backend" or "database" lines.
25
Other database options are described in the
29
directive is allowed by the
33
.B relay <real naming context>
34
The naming context of the database that is presented
35
under a virtual naming context.
36
The presence of this directive implies that one specific database,
37
i.e. the one serving the
38
.BR "real naming context" ,
39
will be presented under a virtual naming context.
44
database does not automatically rewrite the naming context
45
of requests and responses.
48
overlay must be explicitly instantiated, and configured
52
directive suffices if only naming context rewriting is required.
55
One important issue is that access rules are based on the identity
56
that issued the operation.
57
After massaging from the virtual to the real naming context, the
58
frontend sees the operation as performed by the identity in the
62
bypasses the real database frontend operations by short-circuiting
63
operations through the internal backend API, the original database
64
access rules do not apply but in selected cases, i.e. when the
65
backend itself applies access control.
66
As a consequence, the instances of the relay database must provide
67
own access rules that are consistent with those of the original
68
database, possibly adding further specific restrictions.
69
So, access rules in the
71
database must refer to identities in the real naming context.
72
Examples are reported in the EXAMPLES section.
78
directive is given, the
80
database does not refer to any specific database, but the most
81
appropriate one is looked-up after rewriting the request DN
82
for the operation that is being handled.
84
This allows to write carefully crafted rewrite rules that
85
cause some of the requests to be directed to one database, and
86
some to another; e.g., authentication can be mapped to one
87
database, and searches to another, or different target databases
88
can be selected based on the DN of the request, and so.
90
Another possibility is to map the same operation to different
91
databases based on details of the virtual naming context,
92
e.g. groups on one database and persons on another.
95
To implement a plain virtual naming context mapping
96
that refers to a single database, use
100
suffix "dc=virtual,dc=naming,dc=context"
101
relay "dc=real,dc=naming,dc=context"
103
rwm-suffixmassage "dc=real,dc=naming,dc=context"
106
To implement a plain virtual naming context mapping
107
that looks up the real naming context for each operation, use
111
suffix "dc=virtual,dc=naming,dc=context"
113
rwm-suffixmassage "dc=real,dc=naming,dc=context"
116
This is useful, for instance, to relay different databases that
117
share the terminal portion of the naming context (the one that
120
To implement the old-fashioned suffixalias, e.g. mapping
121
the virtual to the real naming context, but not the results
122
back from the real to the virtual naming context, use
126
suffix "dc=virtual,dc=naming,dc=context"
127
relay "dc=real,dc=naming,dc=context"
130
rwm-rewriteContext default
131
rwm-rewriteRule "dc=virtual,dc=naming,dc=context"
132
"dc=real,dc=naming,dc=context" ":@"
133
rwm-rewriteContext searchFilter
134
rwm-rewriteContext searchEntryDN
135
rwm-rewriteContext searchAttrDN
136
rwm-rewriteContext matchedDN
141
overlay is instantiated, but the rewrite rules are written explicitly,
142
rather than automatically as with the
144
statement, to map all the virtual to real naming context data flow,
145
but none of the real to virtual.
151
suffix "dc=example,dc=com"
153
access to dn.subtree="dc=example,dc=com"
154
by dn.exact="cn=Supervisor,dc=example,dc=com" write
158
suffix "o=Example,c=US"
159
relay "dc=example,dc=com"
161
rwm-suffixmassage "dc=example,dc=com"
163
access to dn.subtree="o=Example,c=US"
164
by dn.exact="cn=Supervisor,dc=example,dc=com" write
165
by dn.exact="cn=Relay Supervisor,dc=example,dc=com" write
169
Note that, in both databases, the identities (the
172
.BR "real naming context" ,
174
.BR "`dc=example,dc=com'" ,
175
while the targets (the
180
.BR "virtual naming context" ,
185
backend does not honor any of the access control semantics described in
186
.BR slapd.access (5);
187
all access control is delegated to the relayed database(s).
192
pseudo-attribute and to the other attribute values of the entries
195
operation is honored, which is performed by the frontend.
199
default slapd configuration file
added
removed
doc/man/man5/slapd-relay.5
