Re: (ITS#6567) Enable GSSAPI support and expose ldap_gssadpi_bind_s

[Kurt@OpenLDAP.org]

On Jun 2, 2010, at 1:08 AM, hyc@symas.com wrote:

> ssalley@likewise.com wrote:
>> Full_Name: Scott Salley
>> Version: HEAD
>> OS: Linux
>> URL: =
http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-def=
ine-have-gssapi.patch
>> Submission from: (NULL) (67.51.54.234)
>>=20
>>=20
>> Note that a similar issue/contribution was submitted in 2008 =
(Contrib/5369) and
>> appears to have been 'lost'.
>=20
>> The patch =
http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-def=
ine-have-gssapi.patch
>> makes it possible to use the GSSAPI support in OpenLDAP by:
>>=20
>> 1. Defining --with-gssapi in configure which
>>  a. Checks for appropriate header files
>>  b. Checks for the appropriate library
>>  c. Defines HAVE_GSSAPI to 1 in everything is in order
>>=20
>> 2. Exposing ldap_gssapi_bind_s in ldap.h
>=20
> I am still disinclined to publish any of this. The standard mechanism =
for=20
> using GSSAPI in LDAP is via SASL. I see no benefit to propagating more=20=

> non-standard one-off ldap_XXX_bind flavors. It's a poor design =
approach and it=20
> increases our support workload for no appreciable gain. It increases=20=

> application developer's workload as well, if they have to test for the=20=

> existence of multiple flavors of ldap_XXX_bind and code for them each=20=

> separately in their apps.

I concur and add: At one time I thought it might be useful to implement =
a few SASL mechanisms directly in libldap for cases where one didn't =
want to suck in a SASL library.  But for most mechanisms removing the =
SASL library is worth it in my eyes, especially any mechanism other than =
PLAIN or EXTERNAL.   But where this is worth it, it should be done =
through existing APIs.   Adding mech specific APIs should be avoided.
>=20
> If you really want to have "direct" access to other authentication =
mechanisms,
> the right way to do this is by adding new LDAP_AUTH_xxx definitions =
that can=20
> be muxed out from a single ldap_bind API.

I could see adding new API to support new authentication frameworks to =
which LDAP was extended to support.   For instance, if LDAP was extended =
to directly support GSS API mechanisms, then adding LDAP_AUTH_GSSAPI =
would make sense (here GSS API refers to the GSS API not the SASL =
Kerberos mechanism called GSSAPI).  But for security reasons, it =
unlikely this will ever happen,

=20
> Of course, by the time you've=20
> implemented option parsing so that generic client code can be =
configured with=20
> arbitrary Bind mechanisms, you would have re-implemented SASL.
>=20
> --=20
>   -- Howard Chu
>   CTO, Symas Corp.           http://www.symas.com
>   Director, Highland Sun     http://highlandsun.com/hyc/
>   Chief Architect, OpenLDAP  http://www.openldap.org/project/
>=20
>=20