[Date Prev][Date Next]
Re: Bug in LDAP_CONTROL_PROXY_AUTHZ (ITS#2871)
On Mon, 15 Dec 2003, Pierangelo Masarati wrote:
> > 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 email@example.com -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:
I agree with this. I really do not use realms, but I will need it in the
future. I hope other apps (cyrus-imap, sendmail, etc) will follow this
standard. Unfortunately, a lot of people assume that realm and
domain are the same.
> which allows to specify everything without ambiguity.
> Maybe we can alleviate it to
> (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'
Is -R going to be eliminated?
> 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.
I noticed this. ;) I assume that realm is going to be ignored for mechs
that do not use it?
How is this going to work with GSSAPI?