This guide gives a tutorial on the use of the Cyrus SASL library for a client or server application. It complies with versions including and after 2.0.0. The following pages should only be considered a guide, not the final word on programming with the Cyrus SASL library. Consult the header files in the distribution in the case of ambiguities.
SASL stands for Simple Authentication Security Layer and is explained in RFC 2222. That document is very difficult to understand however and it should be unnecessary to consult it.
Before SASL, when a new protocol was written which required authentication (users proving who they are to an entity), the protocol had to allow explicitly for each individual authentication mechanism. There had to be a distinct way to say "I want to log in with Kerberos V4". There had to be another distinct way to say "I want to log in with CRAM-MD5". There had to be yet a different way to say "I want to log in anonymously," and so on. This was non-ideal for both the protocol and application writers.
Additionally, many programmers were not very familiar with security, so the protocol did support many mechanisms, or worse, they were supported incorrectly. Moreover, when a new authentication es for g and helping to debug installations or authentication problems. For that reason, in addition to the standard SASL return codes, the glue code provides an interface to its seterror function (via sasl_utils_t). This function sets detailed error information for a given connection.
In order to ensure consistency of this information, it is the responsibility of the deepest function with access to the sasl_conn_t make the call to set the errdetail string.
Memory allocation in SASLv2 follows the simple paradigm that if you allocate it, you free it. This improves portability, and allows for a large performance improvement over SASLv1. To prevent memory leaks (especially in the mechanism plugins), please ensure that you follow this paradigm.
Mechanism plugins used to have to worry about the situation where they needed clients to send first (or server to send last), yet the protocol did not support it. Luckily, this is now handled by the glue code, provided that the plugin declares the appropriate flags in the structure returned by its init function. Thus, the step functions will not have to worry about these issues and can be implemented knowing they will be called only when the application actually has data for them and/or will allow them to send data. These flags are as follows:
If neither flag is set, the mechanism will handle the client-send first situation internally, because the client may or may not send first. (e.g. DIGEST-MD5). In this case, the plugin must intelligently check for the presence (or absence) of clientin/serverin data. Note that the optional client send-first is only possible when the protocol permits an initial response.
The server send last situation is handled by the plugin intelligently
setting *serverout when the step function returns SASL_OK. For mechanisms
which never send last (e.g. PLAIN), *serverout must be set to NULL. For
mechanisms which always send last (e.g. DIGEST-MD5), *serverout must
point to the success data. For mechanisms in which the server may or
may not send last (e.g. SRP), *serverout must be set accordingly.
Client Plugins
Client-side mechanism plugins are generally included in the same plugin with their server counterpart, though this is not a requirement. They take care of the client-side of the SASL negotiation. For a simple example, see the ANONYMOUS plugin.
Client plugins must export sasl_client_plug_init which returns a sasl_client_plug_t in order to load. The structure has several functional members and a global context (which applies to all connections using the plugin). The important ones are described briefly here.
Server-side mechanism plugins are generally included in the same plugin with their client counterpart, though this is not a requirement. They take care of the server-side of the SASL negotiation, and are generally more complicated than their client-side counterparts. For a simple example, see the ANONYMOUS plugin.
Server plugins must export sasl_server_plug_init which returns a sasl_server_plug_t in order to load. The structure has several functional members and a global context (which applies to all connections using the plugin). The important ones are described briefly here.
Before returning SASL_OK, mech_step must fill in the oparams fields for which it is responsible, that is, doneflag (set to 1 to indicate a complete exchange), maxoutbuf, or the maximum output size it can do at once for a security layer, mech_ssf or the supplied SSF of the security layer, and encode, decode, encode_context, and decode_context, which are what the glue code will call on calls to sasl_encode, sasl_encodev, and sasl_decode.
User Canonicalization plugins allow for nonstandard ways of canonicalizing the username. They are subject to the following requirements:
User canonicalization plugins must export a sasl_canonuser_init function which returns a sasl_canonuser_plug_t in order to load successfully. They must implement at least one of the canon_user_client or canon_user_server members of the sasl_canonuser_plug_t. The INTERNAL canon_user plugin that is inside of the glue code implements both in the same way.
Perhaps the most exciting addition in SASLv2, Auxprop plugins allow for an easy way to perform password and secret lookups (as well as other information needed for authentication and authorization) from directory services, and in the same request allow the application to receive properties that it needs to provide the service.
Auxprop plugins need to export the sasl_auxprop_init function and pass back a sasl_auxprop_plug_t in order to load successfully. The sasldb plugin included with the Cyrus SASL distribution would be a good place to start.
Interfacing with property contexts is extremely well documented in prop.h and so that is omitted here. The only important note is to be sure that you are using the interfaces provided through the sasl_utils_t structure and not calling the functions directly.
To successfully implement an auxprop plugin there is only one required function to implement, that is the auxprop_lookup member of the sasl_auxprop_plug_t. This is called just after canonicalization of the username, with the canonicalized username. It can then do whatever lookups are necessary for any of the requested auxiliary properties.