The SASL library is called libsasl. libsasl is a framework that allows properly written SASL consumer applications to use any SASL plug-ins that are available on the system. The term plug-in refers to objects that provide services for SASL. Plug-ins are external to libsasl. SASL plug-ins can be used for authentication and security, canonicalization of names, and lookup of auxiliary properties, such as passwords. Cryptographic algorithms are stored in plug-ins rather than in libsasl.
libsasl provides an application programming interface (API) for consumer applications and libraries. A service provider interface (SPI) is provided for plug-ins to supply services to libsasl. libsasl is not aware of the network or the protocol. Accordingly, the application must take responsibility for sending and receiving data between the client and server.
SASL uses two important identifiers for users. The authentication ID (authid) is the user ID for authenticating the user. The authentication ID grants the user access to a system. The authorization ID (userid) is used to check whether the user is allowed to use a particular option.
The SASL client application and SASL server application negotiate a common SASL mechanism and security level. Typically, the SASL server application sends its list of acceptable authentication mechanisms to the client. The SASL client application can then decide which authentication mechanism best satisfies its requirements. After this point, the authentication takes place using the agreed-upon authentication mechanism as a series of client-server exchanges of the SASL supplied authentication data. This exchange continues until the authentication successfully completes, fails, or is aborted by the client or the server.
In the process of authentication, the SASL authentication mechanism can negotiate a security layer. If a security layer is selected, that layer must be used for the duration of the SASL session.
Client and server applications make calls to their local copies of libsasl through the SASL API. libsasl communicates with the SASL mechanisms through the SASL service provider interface (SPI).
Authentication on the client side
Authentication on the server side
Integrity, that is, checking that transmitted data is intact
Confidentiality, that is, encrypting and decrypting transmitted data
SSF, the security strength factor, indicates the strength of the SASL protection. If the mechanism supports a security layer, the client and server negotiate the SSF. The value of the SSF is based on the security properties that were specified before the SASL negotiation. If a non-zero SSF is negotiated, both client and server need to use the mechanism's security layer when the authentication has completed. SSF is represented by an integer with one of the following values:
0 – No protection.
1 – Integrity checking only.
>1 – Supports authentication, integrity and confidentiality. The number represents the encryption key length.
The confidentiality and integrity operations are performed by the security mechanism. libsasl coordinates these requests.
In the negotiation, the SASL client selects the mechanism with the maximum SSF. However, the actual SASL mechanism that is chosen might subsequently negotiate a lower SSF.
Applications communicate with libsasl through the libsasl API. libsasl can request additional information by means of callbacks that are registered by the application. Applications do not call plug-ins directly, only through libsasl. Plug-ins generally call the libsasl framework's plug-ins, which then call the application's callbacks. SASL plug-ins can also call the application directly, although the application does not know whether the call came from a plug-in or from libsasl.
Callbacks are useful in multiple areas, as follows.
libsasl can use callbacks to get information that is needed to complete authentication.
libsasl consumer applications can use callbacks to change search paths for plug-ins and configuration data, to verify files, and to change various default behaviors.
Servers can use callbacks to change authorization policies, to supply different password verification methods, and to get password change information.
Clients and servers can use callbacks to specify the language for error messages.
Applications register two sorts of callbacks: global and session. Additionally, libsasl defines a number of callback identifiers that are used to register for different sorts of callbacks. If a given type of callback is not registered, libsasl takes default action.
Session callbacks override global callbacks. If a session callback is specified for a given ID, the global callback is not called for that session. Some callbacks must be global, because these callbacks occur outside of sessions. The following instances require global callbacks:
Determination of search paths for plug-ins to load
Verification of plug-ins
Location of configuration data
The logging of error messages
Other global configuration of libsasl or its plug-ins
A SASL callback can be registered with a NULL callback function for a given SASL callback ID. The NULL callback function indicates that the client is equipped to supply the needed data. All SASL callback IDs start with the prefix SASL_CB_.
SASL provides the following callbacks for use by either a client or a server:
Gets a SASL option. Options modify the behavior of libsasl(3LIB) and related plug-ins. Can be used by either a client or a server.
32-bit SPARC architecture: /usr/lib/sasl
32-bit x86 architecture: /usr/lib/sasl
64-bit SPARC architecture: /usr/lib/sasl/sparcv9
x64 architecture: /usr/lib/sasl/amd64
SASL provides the following callbacks for use by clients only:
SASL provides the following callbacks for use by servers only:
Checks that an authenticated user is authorized to act on behalf of the specified user. If this callback is not registered, then the authenticated user and the user to be authorized must be the same. If these IDs are not the same, then the authentication fails. Use the server application to take care of nonstandard authorization policies.
When the SASL library is first initialized, the server and client declare any necessary global callbacks. The global callbacks are available prior to and during the SASL sessions. Prior to initialization, callbacks perform such tasks as loading plug-ins, logging data, and reading configuration files. At the start of a SASL session, additional callbacks can be declared. Such callbacks can override global callbacks if necessary.
libsasl uses a SASL connection context to maintain the state of each SASL session for both SASL clients and SASL servers. Each context can be used for only one authentication and security session at a time. The maintained state includes the following information:
Connection information, such as service, naming and address information, and protocol flags
Callbacks specific to the connection
Security properties for negotiating the SASL SSF
State of the authentication along with security layer information