Escaping principalName in LDAP filters

[Cantor, Scott]

On 10/25/13, 7:32 PM, "Elliot Kendall" <elliot.kendall at ucsf.edu> wrote:
>
>But I keep seeing the same thing. Is the LDAPValueEscapingStrategy
>class actually being used? I don't pretend to understand the code to
>any reasonable extent.

The only place I see it used is when values pulled in from dependent *data
connectors* are inserted into the Velocity context. Neither dependent
*attribute definition values*, nor anything pulled in from the resolution
context inside the template (e.g. principalName) appear to be escaped.

I don't know why the attribute definitions wouldn't be escaped, but it's
impractical to do that to things being accessed after injection. Honestly
I disagree with the whole design; escaping is something that has to be
done explicitly within the template, IMHO, not on injection into the
Velocity context. There's no way to "catch" data accessed indirectly on
objects injected into the context, which means it's inconsistent at best
and wrong at worst.

>What's strangest of all is that in production, I see the same behavior
>with aacli, but it *works* using the IdP itself. Maybe just aacli is
>missing the filtering somehow? But in that case, why would it be failing
>for the IdP itself in stage?

AACLI could be doing something implicitly via command line option
processing. Or your command line jars aren't the same as what an IdP is
using.

Bottom line IMHO is that I would forget this approach and if you want to
use user names that are going to cause trouble, process them through a
scriptlet definition to put them into a suitable form for LDAP and then
plug that in as a dependency of the connector.

Or customize your login layer to make sure it only produces workable
principal names (best option).

That's my "me no speak LDAP" advice.

If Daniel/Rod's reading this, I don't think we should port/maintain this
particular bit of code in V3. It looks very iffy to me (that's
notwithstanding the bug).

-- Scott