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

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



On Jun 2, 2010, at 4:28 AM, gcarter@likewise.com wrote:
>=20
> Is it just the public ldap_bind_gssapi_s() signature that you
> have an issue with?  If, as you suggest, we give you a patch
> that adds an LDAP_AUTH_GSSAPI flag to ldap_bind_s() but keep
> the same (existing) ldap_bind_gssapi_s() internals, would that
> be acceptable?

There's already LDAP_AUTH_NEGOTIATE which does this.  So technically, =
the API is already exposed via ldap_bind_s.

But I strongly oppose the introduction of abuse of the LDAP_AUTH_* =
enumeration of LDAP authentication methods and ldap_bind_s().  This =
enumeration and method are intended to have a one-to-one relationship =
with the wire protocol.  There is no "negotiate" LDAP authentication =
mechanism.

If this code is going to pursued (see my other comments), I think it =
should be treated as a high level negotiation wrapper similar to =
ldap_sasl_interactive_bind_s().  If at all possible, it should be =
integrated into ldap_sasl_interactive_bind_s() (which can handle =
non-interactive cases as well).   However, I could (*) see it desirable =
for it to be separately accessible as well, so =
ldap_sasl_gss_spnego_bind_s() would be better.  (* it might be easier to =
see this if a proponent of this feature would implement it in =
ldapwhoami(1) and slapd(8).)

However, I still have objections to releasing code which implements =
undocumented protocol features.  Someone really needs to specify the the =
SASL GSS-SPNEGO mechanism and how its used in LDAP.

-- Kurt=20


>=20
>=20
>=20
>=20
>=20
>=20
> cheers, jerry
> - --=20
> Director of Engineering                      http://www.likewise.com/
> Likewise-CIFS                            http://www.likewiseopen.org/
> "What man is a man who does not make the world better?"      --Balian
>=20
>=20
>=20
>=20
>=20
> On 6/2/10 12:10 AM, Scott Salley wrote:
>>=20
>>=20
>>=20
>> -----Original Message-----
>> From: Howard Chu [mailto:hyc@symas.com]
>> Sent: Tue 6/1/2010 6:07 PM
>> To: Scott Salley
>> Cc: openldap-its@openldap.org
>> Subject: Re: (ITS#6567) Enable GSSAPI support and expose =
ldap_gssadpi_bind_s
>>=20
>> 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
>> using GSSAPI in LDAP is via SASL. I see no benefit to propagating =
more
>> non-standard one-off ldap_XXX_bind flavors. It's a poor design =
approach
>> and it
>> increases our support workload for no appreciable gain. It increases
>> application developer's workload as well, if they have to test for =
the
>> existence of multiple flavors of ldap_XXX_bind and code for them each
>> separately in their apps.
>>=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
>> be muxed out from a single ldap_bind API. Of course, by the time =
you've
>> implemented option parsing so that generic client code can be =
configured
>> with
>> arbitrary Bind mechanisms, you would have re-implemented SASL.
>>=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
>=20
>=20
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>=20
> iD8DBQFMBj/7IR7qMdg1EfYRAjmcAKC1MyKit8TKa1W96cZ2Uh3Cdm/EMACeJtbu
> 9/F8j8UQJ5C3X0sW5LytRq8=3D
> =3DtkYo
> -----END PGP SIGNATURE-----
>=20
>=20