Re: Bug in LDAP_CONTROL_PROXY_AUTHZ (ITS#2871)

[ando@sys-net.it]

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

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