[Date Prev][Date Next]
RE: sasl authz 'dn:' type normalization (ITS#2852)
> I note that the documentation for saslAuthTo/From and sasl-regex imply
> the match parameter is applied against a DN, not an
> authzid. We should clean that up.
> I think it is okay to use ACL-like DN style indicators here,
> but I would prefer that dn: imply dn.exact: not dn.regex:.
> This because the value in dn:value is, per RFC 2829, is a DN.
This was my previous intention, and the sense of the patch
I submutted as ITS#2852; however, this wuould break the
current behavior (which was broken anyway, because applying
dnNormalize to a regex pattern resulted in a failure most
of the times.
> Also, we might consider adding support for other styles (dn.sub,
> dn.children, etc.) where that would make sense. And, u:userid
> might also make sense in some places.
Definitely makes sense.
> At 03:15 PM 12/2/2003, email@example.com wrote:
>>> Is this approach really necessary? Can we just defer the dnNormalize
>>> until after the regexp has been expanded?
>>No, in this case no DN expansion takes place, because
>>it's not a sort of sasl-regexp operation (i.e. a mapping)
>>but rather a match in ACL style (i.e. a DN is tried
>>against a regualr expression to see whether it matches
>>I came out with a more elaborate solution, respectful
>>of current stuff and with better semantics (mutuated from
>>is not normalized, and used as input to regcomp() to
>>compare against assertedDN;
>>is an explicit version of the above
>>is an explicit DN which must pass normalization
>>and exact match. I think this is the least useful,
>>but at last we don't have to apply a regex to
>>strings that require exact match, and we preserve
>>the original behavior of applying regex to "dn:"
>>style saslAuthz* strings. I'm in favour of deprecating
>>their use, and recommend the use of "dn.regex:" or
>>"dn.exact:" for better performance and semantics.
>>I'll commit the patch in a moment.