Re: Bug in LDAP_CONTROL_PROXY_AUTHZ (ITS#2871)

[ando@sys-net.it]

> I needed to change sasl-regex because uid now contains full username
> (userid@domain) and the format of saslAuthzTo changed.  It appears that
> cn=realm is not generated now even though I passed it on the command
> line.  ldapwhoami -U root -R realm -X u=igor@ipass.net -Y digest-md5

Yes, the current code does not allow a realm unless you also
specify a mechanism, but mechanisms are forbidden in
proxyAuthz IDs (sort of a catch 22); I'll see what I can do.

The point is that we found out we cannot rely on <user>@<realm>
syntax because '@' is a legal char both in realms and in usernames,
and many systems rely on this by using email addresses as userids.
So we came out with this user specification:

        u[.<mech>[/<realm>]]:<username>

which allows to specify everything without ambiguity.

Maybe we can alleviate it to

        u[.<mech>][/<realm>]:<username>

(note the square brackets ...), but I need to check security
and generality implications, so that you can use

        ldap* -e '!authzid=u/ipass.net:igor'

for your proxyAuthz control, or

        ldap* -e '!authzid=u.AUTHZ/ipass.net:igor'

where the fake AUTHZ mechanism is accepted.  I favour this
latter solution, and I just checked in the related changes.

Also, note that now the <mech> will always be present
in the SASL name; if one uses simple bind, a fake mechanism
"cn=SIMPLE" will be used.

p.

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