Different SASL mechanisms have different requirements on the application using it. Some simpler mechanisms, such as LOGIN and PLAIN, are straight forward to hook into existing authentication systems (such as /etc/passwd via PAM). The client callback for these mechanisms is easy to implement, the user is simply queried for the username and password. The server callbacks pass on the username and password into the policy deciding authentication system (e.g. PAM).
Other mechanism like CRAM-MD5, DIGEST-MD5, and SRP uses hashed passwords. The client callback are the same as for PLAIN and LOGIN. However, the server do not receive the plaintext password via the network but rather a hash of it. Existing policy deciding systems like PAM cannot handle this, so the server callback for these mechanisms are more complicated.
Further mechanisms like GSSAPI (Kerberos 5) assume a specific authentication system. In theory this means that `Libgsasl' would not need to interact with the application, but rather call this specific authentication system directly. However, some callbacks are supported anyway, to modify the behaviour of how the specific authentication system is used.
Special mechanisms like EXTERNAL and ANONYMOUS are entirely dependent on callbacks.
The EXTERNAL mechanism is used to authenticate a user to SASL when SASL is used in an environment which has already authenticated the user. It is often used within TLS or IPSEC protected channels.
This mechanism is only enabled in the server if you implement the callback below and set them in the library (Chapter 7). It is always enabled in the client as there are no client callbacks.
int (
*Gsasl_server_callback_external) (Gsasl_session_ctx * ctx)
ctx: libgsasl handle.
Type of callback function the application implements. It should return GSASL_OK if user is authenticated by out of band means, otherwise GSASL_AUTHENTICATION_ERROR.