RE: back-relay

["Pierangelo Masarati" <ando@sys-net.it>]

>> -----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.

of course, if one wants to implement enything like this,
its slapd.conf will look like a mess; at least, I strongly
suggest the use of includes ;)

> 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.

In my opinion, a clean solution needs to rewrite everything
back to the virtual naming context, otherwise I don't see the
need of this all.

> 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.

On the contrary, you need one rewrite context for each operation,
and inside each operation's rewrite context you need to select
how to rewrite DNs by doing A LOT OF compare => subst patterns
until you get a match.

>
> 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.

Of course one doesn't need to exploit it this way; cascades
should still be possible, e.g. use one relay to split operations
based on the DN, and redirect them to other relays that do
the specific job for that type of DN, and so... e.g., in your
language example, the virtual n.c. relay would split requests to
other relays, and let requests that do not need internationalization
simply slip thru:

# the frontend relay: English passes thru, Spanish is remapped
database        relay
suffix          "dc=virtual,dc=com"
overlay         rwm
rewriteEngine   on
rewriteContext  default
rewriteRule     "(.*)lang=en,dc=virtual,dc=com$"
        "$1dc=example,dc=com" "@"
rewriteRule     "(.*)lang=([^,]+),dc=virtual,dc=com$"
        "$1lang=$2,dc=lang,dc=com" "@"
rewriteContext  searchResult
rewriteRule     "(.*)dc=lang,dc=com$"
        "$1dc=virtual,dc=com"

# the hispanic relay
database        relay
suffix          "lang=es,dc=lang,dc=com"
overlay         rwm
rewriteEngine   on
rewriteContext  default
rewriteRule     "(.*)lang=es,dc=lang,dc=com$"
        "$1dc=example,dc=com" "@"
rewriteContext  searchResult
rewriteRule     "(.*)dc=example,dc=com$"
        "$1lang=es,dc=lang,dc=com"
map attribute cn cn;lang-es
map attribute sn sn;lang-es
map attribute givenName givenName;lang-es

# the real naming context!
database        bdb
suffix          "dc=example,dc=com"

This could be automated by using includes and generating the per-language
file via m4 or any scripting language... I need to check whether it works,
of course!

Ando

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it