Re: Support for Netscape Directory Server Plug-in API (SLAPI)

["Booker C. Bense" <bbense@networking.stanford.edu>]

On Sat, 8 Sep 2001, Luke Howard wrote:

>
> >- I wrote to the Netscape API about 3 years ago for the NS 3.x ldap
> >server to emulate the Umich style kerberos bind. My feeling at the
> >time was that the interface didn't expose quite enough to be useful.
> >From what I could see, it wasn't possible to write a real SASL Method
> >since there was no way to have a 3-way conversion from the plugin api.
> >Basically, you could only do some variation of EXTERNAL.
>
> Really? We have an implementation of the GSS-API SASL mechanism
> (draft-ietf-cat-sasl-gssapi-05.txt) which works with iPlanet
> Directory Server 3.x to 5.0. The only trick is that, for a multi-
> step SASL bind, you need to maintain a state table keyed by the
> client's connection ID.

- I guess I didn't see far enough.... %-) In retrospect, I was
confusing the c API with the protocol. But IMHO, this is the
kind of thing that should be provided by the API.

>
> >- If you are talking about changing OpenLdap so that modules
> >written to the Netscape API could just "drop in", I think that
> >a large portion could be written as a kind of "backend", but
> >there are certain parts (i.e. the SASL stuff ) that don't
> >fit conviently into ldap's "backend" model.
>
> The SLAPI API supports several different types of plugins,
> including (from slapi-plugin.h):
>
> - extended operation
> - preoperation (called before a backend operation)
> - postoperation (called after a backend operation)
> - matching rule
> - syntax
> - ACL
> - password storage scheme
>
> SASL plugins are preoperation "bind" plugins.

- Hasn't the SASL stuff moved out of the backend and into
the central server itself? Certainly, the pre and post
stuff maps pretty well to the ldap backend model. Although
the netscape stuff is at the "protocol" level and not
the data store.

> I don't think
> OpenLDAP would necessarily need to support this given that
> it already supports the Cyrus plugin API, however this
> mechanism is useful for implementing things like the UMich-
> style Kerberos bind (which I do believe someone has implemented
> for Netscape Directory Server; perhaps UMich themselves?).
>

- I wrote one. I've seen a couple others, it's pretty simple.
Openldap already supports the Umich style kerberos bind.


> It would definitely be good to share the extended operation
> and matching rule (and are there control?) plugins. I'm interested
> in adding Active Directory exop/mrule/controls to OpenLDAP and
> it would be great to get iPlanet support "for free".

- I don't know enough about these to figure out whether you
need to put them in the backend or not. Clearly, things that
operate at the protocol level need to be addressed in the
central server. I can see things getting in a huge mess if
you have X different loadable modules for X different stages
of the process. The most powerful solution would be a generalized
model that encorparates all these things into single point
in the process. This may not be possible with the current
architecture. There are clearly things that you would like
to do that require access both to the procotol level and
the data store. If you make the method general enough it
should be possible to write glue code that would adapt
a "netscape or AD" module to the more general module.

- Perhaps an interesting first step would be to implement
the backends as stackable modules, much like you can stack I/0
streams. There is already much more support for loadable modules
than I realized in the current src.

- Booker C. Bense