Re: defines for each sasl mech?

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 01:59 PM 7/23/99 -0400, shltch@osfmail.isc.rit.edu wrote:
>Hello all,
>
>I was adding GSS authentication to OpenLDAP 1.2.3...

OpenLDAP 1.x is LDAPv2+.  New authentication mechanisms should
be added to -devel as SASL mechanisms.

>, but then I checked out
>OpenLDAP 2.0 devel, and noticed many of the SASL plugs have been started.

Yes, SASL bind protocol support is in place.  I was working on
a DIGEST-MD5 implementation but got side tracked.

>Not wanting to duplicate work, I am now considering moving my changes over
>to new OpenLDAP 2.0-devel.  My question is, do we want a #define HAVE_XXX
>for every supported SASL mechanism? If that was the plan, or if that's a
>good idea, then I'll add a #define HAVE_SASL_GSS or #define HAVE_GSS.

HAVE_XXX are conditional build macros which are mostly generated
by configure.  A macro HAVE_CMU_SASL, for example, would indicate
availability of the CMU SASL library.  Normally there would be a
with flag (ie: --with-cmu-sasl) to determine if configure were to
look for CMU.  Actually mechanisms would be enabled using specific
enable flags (ie: --enable-sasl-digest).

Each with/enable flag normally enables some number of macros which
can then be used in the implementation.  However, HAVE_* macros
are NEVER to be exposed to applications outside of the OpenLDAP
implementation.  That is, no installed header should ever depend
upon a configure defined HAVE_* macro.

So, how is a application to determine which SASL mechanisms are
supported by the client API?   By using LDAP_API_FEATURE macros
and/or ldap_get_option().  (which implies that some --enable/--with
options imply API features... see the thread features for an
example of how this works in practice).

The root DSE 'supportedSASLmechanism' attributes should be searched
to determine which mechanisms a server supports.

>I am thinking about how to tell the server to accept the GSS mech. for
>SASL.  Should there be a command line argument (such as -g), a #define in
>the source, or should it just setup GSS contexts, and use them only if
>client requests?  Our work here requires GSS, but since other won't use
>it, I wanted to inquire as to the best way to make it an option.

Initially, it should be a configure option (which implied a set
of macros that can be used to include the support).  Eventually,
we'd like to support dynamically loadable SASL mechanisms and
configuration control for which mechanisms to support.   That is,
the code may be compiled with DIGEST-MD5, but the user may want
to disallow it's use.  This will all get sorted out over time.

Kurt