On Jun 2, 2010, at 4:28 AM, gcarter(a)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(a)openldap.org
> Subject: Re: (ITS#6567) Enable GSSAPI support and expose =
ldap_gssadpi_bind_s
>=20
> ssalley(a)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