RE: back-relay

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: owner-openldap-devel@OpenLDAP.org
> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Pierangelo Masarati

> > Can we rewrite the operation differently for different authzDNs?
> > (as I think I know the answer, you can take this more as a
> suggestion
> > than a question)

> Let me clarify this a bit:
> 1) we should add a rule that allows to rewrite the authzDN;
> 2) rewriting the authzDN should allow to take different measures
>    based on the value of the authzDN, including the possibility
>    to change how the request DN (field o_req_[n]dn of the slap_op
>    structure) is rewritten;
> 3) since back-relay can be instructued to use the rewritten
>    request DN to select the most appropriate database for each
>    operation, this means that we'd be able to influence what
>    database is selected for each operation based on the authzDN.
> 4) the writing of these rules may not be trivial; we need to
>    provide examples and guidelines, and there might be drawbacks,
>    limitations and side effects I'm not totally aware of, right
>    now.
>
> Of course, step (1) is not available yet...
> A simple choice is to inject it into the rewrite session as soon
> as possible in formm of a parameter, e.g. a string that is
> available to the rewrite engine.  Then it can be used to influence
> rule evaluation, by doing things like:
>
> # rewrite a DN by appending the authzDN:
> rewriteRule ".*" "%0<>%{authzDN}" ":"
> # take measures based on the authzDN:
> rewriteRule "(.*)<>uid=someone,.*" "ou=Special,dc=example,dc=com" "@"
> rewriteRule "(.*)<>uid=([^,]+),.*" "ou=Users,dc=example,dc=com" "@"
> rewriteRule "(.*)<>.*" "ou=Other,dc=example,dc=com" "@"
>
> We can provide a set of default parameters that can be injected
> into a rewrite session (whose scope is connection-wide) and that
> are activated by specific configuration flags in the rewrite-remap
> overlay.

Sounds good, but I'm afraid we're looking at a data explosion in slapd.conf
when someone tries to make use of it all. Also we somehow need to record
state about the original authzDN, because after rewriting all the DNs
associated with a request we need to be able to perform the corresponding
reverse transformations on the responses, and with all these additional
rewrite steps, it's no longer clear what transformations need to be reversed.
I guess you need a separate rewrite context for each destination. Really you
need hierarchical/nested rewrite contexts to be able to manage this
intelligibly.

There's definitely a lot of power in this idea. It provides yet another way
to delegate admin authority (rewrite incoming authzDN to rootdn of target
database), for one thing. It also provides a mechanism for expressing
localization preferences for clients that don't understand tagging. (E.g.,
bind as "cn=Joe,lang=en,ou=people" vs "cn=Joe,lang=es,ou=people" and map all
requested attributes to the appropriately tagged versions)

But it also sounds too complicated... It may be simpler to reduce the
flexibility of a single relay instance, and use multiple (cascaded) relay
instances to assemble more complex layouts.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support