Re: Bug in LDAP_CONTROL_PROXY_AUTHZ (ITS#2871)

[igor@ipass.net]

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

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.

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

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?

-- 
Igor