[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#6817) idassert-bind with SASL issues



> masarati@aero.polimi.it wrote:
>> Full_Name: Pierangelo Masarati
>> Version: HEAD/re24
>> OS: irrelevant
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (2.40.14.92)
>> Submitted by: ando
>>
>>
>> When idassert-bind is configured to use SASL bind, an "authcID" needs to
>> be
>> provided, while the "binddn" is not needed.  However, if a "binddn" is
>> not
>> provided as well, in some cases the proxiedAuthz control may be used
>> incorrectly.  The need to configure the "binddn" is not documented, so
>> this ITS
>> is minimally addressed by documenting this requirement.
>
> I tripped over this change while investigating #6711. Adding this
> requirement
> is certainly not the right solution; SASL Binds ordinarily don't require a
> BindDN and requiring it here just makes things confusing.

I understand the fix I'm suggesting can sound counter-intuitive.  The
documentation should clearly indicate that the binddn in case of SASL is
for *local* and *internal* issues, and will not be part of the
authentication process.  As an alternative, lc_bound_ndn could receive a
dummy DN (e.g. "cn=auth") to merely indicate a successful bind (or receive
the actual identity from the remote server using the authid control along
with the bind or performing a whoami extop later, as already implemented).

p.

> Also with the fixes that I made for #6711 I don't believe the issue exists
> any
> more. Please describe the conditions where the problem occurs.
>
>> If the "binddn" is provided, everything works as expected, with the only
>> minor
>> issue that the DN of the user as it is known to back-meta may not match
>> the
>> actual identity the "authcID" assumed on the remote server.  The "right"
>> way to
>> address this problem consists in performing a "WhoAmI" (RFC 4532) right
>> after
>> the bind, or better use a "authorization identity control" (RFC 3829)
>> along with
>> the bind operation.  Both approaches should be implemented, but they
>> should not
>> be used unless explicitly requested.
>
> --
>    -- Howard Chu
>    CTO, Symas Corp.           http://www.symas.com
>    Director, Highland Sun     http://highlandsun.com/hyc/
>    Chief Architect, OpenLDAP  http://www.openldap.org/project/
>
>