Re: GSSAPI signing/encryption for unsuspectingly applications (its not a bug)
On Jul 2, 2009, at 2:49 AM, Howard Chu wrote:
Rafal Szczesniak wrote:
> On Wed, May 13, 2009 at 03:06:57PM -0700, Howard Chu wrote:
>> mikbec wrote:
>>> Patch related to "(ITS#6110) GSSAPI signing/encryption for
>>> unsuspectingly applications" is more an enhancement than a bug
>>> report.
>>
>> That's fine, patches are supposed to be tracked in ITS anyway.
>>
>> However, it seems to me that these patches are duplicating
>> functionality
>> that's already provided by SASL/GSSAPI. On that basis I'm inclined
>> to
>> reject them. I'm beginning to regret including the
>> ldap_gssapi_bind_s()
>> function as well; that is totally nonstandard and duplicates
>> functionality that has been available in the standard API for over 8
>> years.
>
> ldap_gssapi_bind was never meant to replace or duplicate SASL part
> of the code.
> It's only an implementation that enables using GSSAPI directly,
> while Cyrus
> SASL offers wide variety of authentication mechanisms. The
> difference is
> that ldap_gssapi_bind doesn't require any special configuration and
> thus
> it's an easy way to have an interface for Active Directory.
This explanation makes no sense, since no *special* configuration is
required to use SASL/GSSAPI with Active Directory. No matter what
API you use, you must have Kerberos properly configured.
I would be concerned for having two APIs that do the same thing. This
complicates clients.
I've long thought about implementing certain SASL mechanism natively,
such as PLAIN and EXTERNAL, because at times I rather not deal with
Cyrus SASL (or other SASL library alternatives). (I never did it
because, well, because those times are rare.) BUT I think native
implementations should present themselves with the same API.
If not, what happens is that client's end up having to have some
configuration support (or other means) to select which implementation
to use.
-- Kurt