[Date Prev][Date Next]
Re: Support for Netscape Directory Server Plug-in API (SLAPI)
>- 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.
>- 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
- password storage scheme
SASL plugins are preoperation "bind" plugins. 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?).
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".
Luke Howard | lukehoward.com
PADL Software | www.padl.com