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
- 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
-
Kurt＠OpenLDAP.org