Re: OATH HOTP authentication with OpenLDAP

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

(Copying some of this from an IRC conversation)

Dimitri writes:
> 1. We have chosen to use SLAPI, not overlay API, to make our
> authentication plugin portable to other LDAP servers; but still our main
> target is OpenLDAP and we're not going to migrate to any other LDAP
> server (but our clients might). In terms of SLAPI, this will be a
> "preoperation bind plugin". If somebody thinks our choice is awfully
> bad, please don't hesitate to share your considerations.

Normally the simplest way would be to make new password scheme,
maybe {OATH-HOTP} which takes the user name as a value.  Then put
    userPassword: {OATH-HOTP}mitya
in your entry.  See contrib/slapd-modules/passwd/README.

Except I'm not sure how to best make a password plugin look up anyting
in LDAP, like you are planning (your point 6).  The right way is
presumably via slapd internals - retrieve the thread and memory context,
create a fake (internal) operation, use be_search.  Or I suppose you
could make it a regular LDAP client which talks to slapd over the LDAP
protocol (maybe over ldapi://), but that seems rather weird.  I wonder
if that could potentially freeze all threads in a deadlock if you do it
wrong.  In OpenLDAP, each active LDAP request uses one thread.
But I think SASL can do the same, so maybe it's OK.

I don't know slapi if you stay with that, but anyway:

> 2. Another reason for choosing SLAPI was much clearer API and, most
> importantly, availability of simple, synchronous functions for
> performing internal operations (searches, modifications). It seemed to
> me that overlay API provides only complex, callback-based functions for
> internal operations. Please let me know if I've overlooked that in the
> documentation (or, better say, source code, since overlay API is
> actually undocumented, opposite to SLAPI [2]).

See above.  But for slapi vs overlays, not really.  Some of the small
overlays can be used for templates, and there are postings floating
around with slapd internals.  E.g. this one (now somewhat obsolete):
  http://www.openldap.org/lists/openldap-devel/200803/msg00054.html

> 3. Current state of SLAPI support in OpenLDAP completely lacks functions
> like slapi_is_root_suffix(), slapi_dn_isroot(), as well as  the whole
> slapi_be_* function family. This makes impossible to determine root DN
> for authenticating principal.

slapi code is supposed to be portable to other servers, which might not
have a concept like root DN.

> 4. (SLAPI plugins configuration)

Don't know.

> 5. HOTP algorithm uses SHA1 cryptographic hash. We clearly understand
> that if using SLAPI we won't be able to use OpenLDAP SHA1 implementation
> available via lutil_sha1.h. In order not to implement SHA1 ourselves, is
> it okay to introduce a dependency on OpenSSL/GnuTLS/NSS? For example,
> two RedHat plugins from their distribution (namely "http" and
> "pwdstorage" [3]) do use NSS and hence include ssl.h.

Should work fine, unless you are linking a different library version of
what OpenLDAP uses.  Or sometimes even then, depending on how well the
OS isolates linked library namespaces from each other.

However this may complicate things for your users: How to get a library
to load another library requires OS-dependent linker options.  You might
prefer to copy someone's sha1 code.  E.g. the one in OpenLDAP.  Along
with any COPYING file or whatever their copyright might require.

Or use lutil_sha1.h anyway as long as you're only using slapi for its
simple interface, and worry about porting to other servers when the time
comes when someone wants to do that.

Avoid GnuTLS:
   GnuTLS considered harmful
   http://www.openldap.org/lists/openldap-devel/200802/msg00072.html
It has been cleaned up somewhat since then, but nothing I've heard suggests
it's now good enough to trust it.

-- 
Hallvard