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

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



ssalley@likewise.com wrote:
> Full_Name: Scott Salley
> Version: HEAD
> OS: Linux
> URL: http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-define-have-gssapi.patch
> Submission from: (NULL) (67.51.54.234)
>
>
> Note that a similar issue/contribution was submitted in 2008 (Contrib/5369) and
> appears to have been 'lost'.

> The patch http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-define-have-gssapi.patch
> makes it possible to use the GSSAPI support in OpenLDAP by:
>
> 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
>
> 2. Exposing ldap_gssapi_bind_s in ldap.h

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.

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.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/