Basic processing
The following section describes the typical flow when a SASL plug-in is used to provide an extended authentication function.
- Application calls ldap_sasl_bind_s(), with a mechanism supported by a configured SASL plug-in.
- The LDAP library calls the SASL bind worker function, as provided
by the appropriate plug-in. The parameters that are supplied on the
original ldap_sasl_bind_s() API are passed to
the plug-in as elements of a
pblockstructure. - The plug-in worker function receives control, and extracts the
parameters from the
pblockby using the ldap_plugin_pblock_get() API. The following SASL-related information can be obtained from thepblockby the plug-in:- Distinguished Name (
dn) - Credentials
- Server controls
- Client controls
- Mechanism (plug-in subtype)
- Plug-in configuration information (that is, configuration information that is supplied in ARGC and ARGV form)
- Target LDAP server host name
- Distinguished Name (
- The plug-in runs its mechanism-specific logic. Some of the sample
mechanisms that can be implemented as SASL plug-ins are as follows.
They can be made available to all LDAP applications that are running
on the system:
- Authentication that is based on a user fingerprint (for example, mechanism=userfp)
- When the fingerprint plug-in gets control, it uses the DN supplied
on the ldap_sasl_bind_s() API to obtain an image
of the user fingerprint. This authentication can entail prompting
the user to use a fingerprint-scanning device. In this example, the
fingerprint image, however obtained, represents the user credentials.
When the credentials are obtained, the plug-in is ready to run the actual SASL bind. This authentication is done by calling the ldap_plugin_sasl_bind_s() API, supplying the appropriate parameters (DN, credentials, mechanism, server controls). This API is a synchronous API that sends the SASL bind request to the LDAP server. Two items are returned to the plug-in when the bind result is returned from the server, and control is returned to the plug-in:
- Bind result error code
- Server credentials
If the server credentials are to be returned to the application, they must be set in the
pblockbefore it returns control to the LDAP library, and after to the application. This setting is done by using ldap_plugin_pblock_set(). In this example, the plug-in work is complete, and it returns, supplying the bind result error code as the return code. - Authentication by using credentials that are previously established by the operating system
- When the plug-in gets control, it queries the local security context
to obtain the user identity and security token. For this example,
we assume the user identity, as associated with the local security
context, is used to construct the DN. The information from the security
token is used for credentials.
After the credentials are obtained, the plug-in calls ldap_plugin_sasl_bind_s(), supplying the appropriate parameters (DN, credentials, mechanism, server controls). As in the previous example, the plug-in waits for the results of the bind request, then returns to the LDAP library, again setting server credentials in the
pblock, if appropriate. Control is then returned to the application, along with the optional server credentials. - Authentication by using multiple binds (mechanism=DIGEST-MD5)
- Some SASL mechanisms require multiple transactions between the client and the server (for example, the SASL DIGEST-MD5 mechanism). For this type of mechanism, when the plug-in gains control, it actually calls the ldap_plugin_sasl_bind_s() API multiple times. On each bind operation, the plug-in can supply DN, credentials, mechanism, and server controls, which are passed to the server. The LDAP server can return a result and server credentials back to the client. The plug-in can use this information to formulate another bind, again sent to the server by using ldap_plugin_sasl_bind_s(). When the multi-bind flow is complete, the plug-in returns control to the LDAP library with the result and optional server credentials.