On Jun 2, 2010, at 1:08 AM, [email protected] wrote:
> [email protected] 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
