[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: back-relay

> 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

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


Pierangelo Masarati