Re: Bug in LDAP_CONTROL_PROXY_AUTHZ (ITS#2871)

[igor@ipass.net]

Thanks.

Is this patch going to be backported to 2.1.x?

-Igor

On Mon, 15 Dec 2003, Pierangelo Masarati wrote:

>
> >
> > 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?
>
> No, this is the realm used for SASL authc (by those mechs
> that require it).  If they set the realm in the SASL
> authc, that one is used.  The realm you can supply in the
> proxyauthz control is used only if it is not st by SASL.
>
> In other words, the proxyAuthz'd ID inherits SASL realm
> and mechnism from the authc ID; if the latter does not set
> any, you can explicitly set the realm by the mechanism
> illustrated above.  However you cannot override the mech,
> which is set to SIMPLE if no SASL auth took place.  This
> is for security reasons.
>
> >
> >> 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?
>
> yes.
>
> >
> > How is this going to work with GSSAPI?
>
> GSSAPI should hve the realm and the mech set appropriately
> by the SASL authc, AFAIK.
>
> p.
>
>

-- 
Igor