Client plug-ins are used to manage the client-side of a SASL negotiation. Client plug-ins are usually packaged with the corresponding server plug-ins. A client plug-in contains one or more client-side SASL mechanisms. Each SASL client mechanism supports authentication, and optionally integrity and confidentiality.
Each SASL client mechanism provides information on that mechanism's capabilities:
Maximum SSF
Maximum security flags
Plug-in features
Callbacks and prompt IDs for using the plug-in
Client plug-ins must export sasl_client_plug_init(). libsasl calls sasl_client_plug_init() to initialize the plug-in for the client. The plug-in returns a sasl_client_plug_t structure.
The sasl_client_plug_t provides the following entry points for libsasl to call the mechanism:
mech_new() – The client starts a connection by calling sasl_client_start(), which uses mech_new(). mech_new() performs initialization that is specific to the mechanism. If necessary, a connection context is allocated.
mech_step() – mech_step() can be called by sasl_client_start() and sasl_client_step(). mech_step() performs authentication on the client side after mech_new() has been called. mech_step() returns SASL_OK if authentication is successful. SASL_CONTINUE is returned if more data is required. A SASL error code is returned if authentication fails. If an error occurs, then seterror() is called. If the authentication is successful, mech_step() must return the sasl_out_params_t structure with the relevant security layer information and callbacks. The canon_user() function is part of this structure. canon_user() must be called when the client receives the authentication and authorization IDs.
mech_dispose() – mech_dispose() is called when the context can be safely closed. mech_dispose() is called by sasl_dispose().
mech_free() – mech_free() is called when libsasl shuts down. Any remaining global state for the plug-in is freed by mech_free().