SLAPD-RELAY(5)            FILE FORMATS             SLAPD-RELAY(5)


     slapd-relay - relay backend to slapd




     The primary purpose of this slapd(8) backend  is  to  map  a
     naming  context  defined  in  a database running in the same
     slapd(8) instance into a virtual naming context, with attri-
     buteType  and  objectClass  manipulation,  if  required.  It
     requires the rwm overlay.

     This backend and the above mentioned overlay are  experimen-


     The following slapd.conf directives apply to the relay back-
     end  database.  That is, they must follow a "database relay"
     line and come before any subsequent "backend" or  "database"
     lines.    Other   database  options  are  described  in  the
     slapd.conf(5) manual page;  only  the  suffix  directive  is
     required by the relay backend.

     relay <real naming context> [massage]
          The naming context of the database  that  is  presented
          under  a  virtual naming context.  The presence of this
          directive implies that one specific database, i.e.  the
          one  serving the real naming context, will be presented
          under  a  virtual  naming  context.    This   directive
          automatically  instantiates  the  rwm  overlay.  If the
          optional massage keyword is present, the suffix massag-
          ing  is  automatically  configured  as well; otherwise,
          specific massaging instructions are required  by  means
          of the rewrite directives described in slapo-rwm(5).


     One important issue is that access rules are  based  on  the
     identity  that  issued  the operation.  After massaging from
     the virtual to the real naming context,  the  frontend  sees
     the  operation as performed by the identity in the real nam-
     ing context.  Moreover, since back-relay bypasses  the  real
     database  frontend operations by short-circuiting operations
     thru the internal backend API, the original database  access
     rules  do  not  apply  but  in selected cases, i.e. when the
     backend itself applies access control.   As  a  consequence,
     the  instances of the relay database must provide own access
     rules that are consistent with those of the  original  data-
     base,  possibly  adding  further specific restrictions.  So,
     access rules in the relay database must refer to  identities
     in  the  real  naming context.  Examples are reported in the

OpenLDAP 2.3.27      Last change: 2006/08/19                    1

SLAPD-RELAY(5)            FILE FORMATS             SLAPD-RELAY(5)

     EXAMPLES section.


     If no relay directive is given, the relay database does  not
     refer to any specific database, but the most appropriate one
     is looked-up after rewriting the request DN for  the  opera-
     tion that is being handled.

     This allows to write carefully crafted  rewrite  rules  that
     cause  some  of the requests to be directed to one database,
     and some to another; e.g., authentication can be  mapped  to
     one  database,  and searches to another, or different target
     databases can be selected based on the DN  of  the  request,
     and so.

     Another possibility is to map the  same  operation  to  dif-
     ferent databases based on details of the virtual naming con-
     text, e.g. groups on one database and persons on another.


     The rwm overlay is experimental.


     To implement a plain virtual  naming  context  mapping  that
     refers to a single database, use

       database        relay
       suffix          "dc=virtual,dc=naming,dc=context"
       relay           "dc=real,dc=naming,dc=context" massage

     To implement a plain virtual  naming  context  mapping  that
     looks up the real naming context for each operation, use

       database        relay
       suffix          "dc=virtual,dc=naming,dc=context"
       overlay         rwm
       suffixmassage   "dc=real,dc=naming,dc=context"

     This is useful, for instance, to relay  different  databases
     that  share  the terminal portion of the naming context (the
     one that is rewritten).

     To implement the old-fashioned suffixalias, e.g. mapping the
     virtual to the real naming context, but not the results back
     from the real to the virtual naming context, use

       database        relay
       suffix          "dc=virtual,dc=naming,dc=context"
       relay           "dc=real,dc=naming,dc=context"
       rewriteEngine   on
       rewriteContext  default

OpenLDAP 2.3.27      Last change: 2006/08/19                    2

SLAPD-RELAY(5)            FILE FORMATS             SLAPD-RELAY(5)

       rewriteRule     "dc=virtual,dc=naming,dc=context"
               "dc=real,dc=naming,dc=context" ":@"
       rewriteContext  searchFilter
       rewriteContext  searchEntryDN
       rewriteContext  searchAttrDN
       rewriteContext  matchedDN

     Note that the virtual database is bound  to  a  single  real
     database,  so the rwm overlay is automatically instantiated,
     but the rewrite rules are written explicitly to map all  the
     virtual  to  real  naming context data flow, but none of the
     real to virtual.

     Access rules:

       database        bdb
       suffix          "dc=example,dc=com"
       # skip...
       access to dn.subtree="dc=example,dc=com"
               by dn.exact="cn=Supervisor,dc=example,dc=com" write
               by * read

       database        relay
       suffix          "o=Example,c=US"
       relay           "dc=example,dc=com" massage
       # skip ...
       access to dn.subtree="o=Example,c=US"
               by dn.exact="cn=Supervisor,dc=example,dc=com" write
               by dn.exact="cn=Relay Supervisor,dc=example,dc=com" write
               by * read

     Note that, in both  databases,  the  identities  (the  <who>
     clause)    are    in   the   real   naming   context,   i.e.
     `dc=example,dc=com', while the targets (the  <what>  clause)
     are  in  the real and in the virtual naming context, respec-


     The relay backend does not honor any of the  access  control
     semantics  described  in slapd.access(5); all access control
     is delegated to the relayed  database(s).   Only  read  (=r)
     access to the entry pseudo-attribute and to the other attri-
     bute values of the entries returned by the search  operation
     is honored, which is performed by the frontend.


          default slapd configuration file


     slapd.conf(5), slapo-rwm(5), slapd(8).

OpenLDAP 2.3.27      Last change: 2006/08/19                    3

Man(1) output converted with man2html