2 <title>SASL Plugin Programmer's Guide</title>
3 <!-- $Id: plugprog.html,v 1.5 2002/05/07 15:13:45 ken3 Exp $ -->
6 <h1>SASL Plugin Programmer's Guide</h1>
8 <h3>NOTE: This is a work in progress. Any contributions would be
9 <i>very</i> appreciated</h3>
12 <li><a href="#intro">Introduction</a></li>
14 <li><a href="#about_this_guide">About this Guide</A></li>
15 <li><a href="#about_sasl">What is SASL</A></li>
17 <li><a href="#common">Common Section</a></li>
19 <li><a href="#overview">Overview of Plugin Programming</a></li>
20 <li><a href="#sasl_utils_t">Use of sasl_utils_t</a></li>
21 <li><a href="#error_reporting">Error Reporting</a></li>
22 <li><a href="#memory">Memory Allocation</a></li>
23 <li><a href="#cslssl">Client Send First / Server Send Last</a></li>
25 <li><a href="#client">Client Plugins</a></li>
26 <li><a href="#server">Server Plugins</a></li>
27 <li><a href="#canon_user">User Canonicalization (canon_user) Plugins</a></li>
28 <li><a href="#auxprop">Auxiliary Property (auxprop) Plugins</a></li>
31 <a name="intro"><h2>Introduction</h2></a>
33 <a name="about_this_guide"><h3>About this Guide</h3></a>
35 <p>This guide gives a <i>very</i> brief overview on the things that one
36 needs to know to write a mechanism for the SASLv2 API (and thus
37 Cyrus SASLv2). Note that this page is a brief overview <i>only</i>
38 and that the authoritative documentation are the header files
39 included in the SASL distribution. If you have any questions, please
40 feel free to contact the Cyrus development team at
41 <a href="mailto:cyrus-bugs@andrew.cmu.edu"><i>cyrus-bugs@andrew.cmu.edu
42 </i></a> or the cyrus-sasl mailing list at
43 <a href="mailto:cyrus-sasl@andrew.cmu.edu"><i>cyrus-sasl@andrew.cmu.edu
46 <p>Please note that this guide is only intended for developers looking
47 to write mechanisms for the SASLv2 API, and that application programmers
48 should be reading <a href="programming.html">this document</a> instead.
51 <a name="about_sasl"><h3>What is SASL?</h3></a>
52 <p>A description of SASL is covered in detail in the
53 <a href="programming.html">programmer's guide</a>, which mechanism
54 developers should probably read first anyway to become familiar
55 with development using the SASL library.
58 <a name="common"><h2>Common Section</h2></a>
59 <a name="overview"><h3>Overview of Plugin Programming</h3></a>
61 <p>The basic idea behind programming plugins for Cyrus SASL rests in
62 the ability to dlopen a shared library. Thus, all plugins should
63 be shared libraries. It is recommended that they are libtool
64 libraries for portability reasons (Cyrus SASL parses .la files to
65 get the appropriate name to dlopen), but they can have an extention
67 <p>All plugins should live in the same directory
68 (generally /usr/lib/sasl2), which the glue code (that is, the interface
69 layer that sits between the plugins and the application) scans
70 when one of the init functions (sasl_server_init or sasl_client_init)
71 is called. Cyrus SASL then attempts to open each library and
72 run an initialization function. If the initialization function
73 succeeds, and the versions match, then the glue code determines
74 that the load was successful and the plugin is available for use.</p>
75 <p>There are serveral types of plugins (note that a given plugin library
76 may contain any or all of the following in combination, though
77 such a plugin would be a beast!):</p>
79 <li><b>Mechanism Plugins</b> - These plugins implement mechanisms
80 for authentication, and are the majority of the plugins included
81 with Cyrus SASL. Generally implementing both a client and a server
82 side they take care of the authentication process.</li>
83 <li><b>User Canonicalization Plugins</b> - These plugins enable differing
84 ways of canonicalizing authentication and authorization IDs.</li>
85 <li><b>Auxiliary Property Plugins</b> - These plugins allow auxilliary
86 properties about user accounts to be looked up, such as passwords.
87 Cyrus SASL includes a plugin to read sasldb files, for example.</li>
90 <a name="sasl_utils_t"><h3>Use of sasl_utils_t</h3></a>
92 <p>Because of the way that shared library plugins are loaded for both
93 speed and namespace reasons, the symbol tables are not shared across
94 plugins. Thus, the only interface that the plugin should assume it
95 has to the outside world is through the <tt>sasl_utils_t</tt> structure (or
96 through links that it specifically requires). Likewise, the glue code
97 has no (and will use no) interface into the plugin other than the
98 contents of the structures that are passed back to it by the
99 initialization function.</p>
100 <p>This should be stressed again: do not assume you have access to any
101 functions except through links that your library explicitly makes
102 or through what is provided via the <tt>sasl_utils_t</tt> structure.</p>
104 <a name="error_reporting"><h3>Error Reporting</h3></a>
105 <p>Error reporting is very important for failed authentication tracking
106 and helping to debug installations or authentication problems. For
107 that reason, in addition to the standard SASL return codes, the
108 glue code provides an interface to its seterror function (via
109 <tt>sasl_utils_t</tt>). This function sets detailed error information for
110 a given connection.</p>
111 <p><i>In order to ensure consistency of this information, it is the
112 responsibility of the deepest function with access to the sasl_conn_t
113 make the call to set the errdetail string.</i></p>
115 <a name="memory"><h3>Memory Allocation</h3></a>
116 <p>Memory allocation in SASLv2 follows the simple paradigm that if you
117 allocate it, you free it. This improves portability, and allows
118 for a large performance improvement over SASLv1. To prevent memory
119 leaks (especially in the mechanism plugins), please ensure that you
120 follow this paradigm.</p>
122 <a name="cslssl"><h3>Client Send First / Server Send Last</h3></a>
123 <p>Mechanism plugins used to have to worry about the situation
124 where they needed clients to send first (or server to send last), yet
125 the protocol did not support it. Luckily, this is now handled by
126 the glue code, provided that the plugin declares the appropriate flags
127 in the structure returned by its init function. Thus, the step functions
128 will not have to worry about these issues and can be implemented
129 knowing they will be called only when the application actually has
130 data for them and/or will allow them to send data. These flags are as
133 <li><B>SASL_FEAT_WANT_CLIENT_FIRST</B>: The mechanism has the client
134 side send first always. (e.g. PLAIN)</li>
135 <li><B>SASL_FEAT_SERVER_FIRST</B>: The mechanism has the server side
136 send first always. (e.g. CRAM-MD5)</li>
139 <p>If neither flag is set, the mechanism will handle the client-send
140 first situation internally, because the client may or may not send
141 first. (e.g. DIGEST-MD5). In this case, the plugin must
142 intelligently check for the presence (or absence) of clientin/serverin
143 data. Note that the optional client send-first is only possible when the
144 protocol permits an initial response.
146 <p>The server send last situation is handled by the plugin intelligently
147 setting *serverout when the step function returns SASL_OK. For mechanisms
148 which never send last (e.g. PLAIN), *serverout must be set to NULL. For
149 mechanisms which always send last (e.g. DIGEST-MD5), *serverout must
150 point to the success data. For mechanisms in which the server may or
151 may not send last (e.g. SRP), *serverout must be set accordingly.
153 <a name="client"><h2>Client Plugins</h2></a>
154 <p>Client-side mechanism plugins are generally included in the same
155 plugin with their <a href="#server">server</a> counterpart, though
156 this is not a requirement. They take care of the client-side of the
157 SASL negotiation. For a simple example, see the ANONYMOUS plugin.</p>
158 <p>Client plugins must export <tt>sasl_client_plug_init</tt> which returns
159 a <tt>sasl_client_plug_t</tt> in order to load. The structure has
160 several functional members and a global context (which applies to
161 all connections using the plugin). The important ones are described
164 <li><b>mech_new</b> - Called at the beginning of each connection,
165 (on a call to sasl_client_start),
166 mech_new does mechanism-specific initialization, and if necessary
167 allocates a connection context (which the glue code keeps track
168 of for it). mech_new does not actually send any data to the client,
169 it simply allocates the context.</li>
170 <li><b>mech_step</b> - Called from <tt>sasl_client_start</tt> and
171 <tt>sasl_client_step</tt>, this function does the actual work of
173 side of the authentication. If authentication is successful, it
174 should return SASL_OK, otherwise it should return a valid SASL
175 error code (and call seterror). This should also set up the
176 oparams structure before returning SASL_OK, including any
177 security layer information (in the way of callbacks). Note
178 that as soon as the client has both the authentication and
179 authorization IDs, it MUST call the canon_user function provided
180 in its params structure (for both the authentication and
181 authorization IDs, with SASL_CU_AUTHID and SASL_CU_AUTHZID
183 <li><b>mech_dispose</b> - Called to dispose of a connection context.
184 This is only called when the connection will no longer be used
185 (e.g. when <tt>sasl_dispose</tt> is called)</li>
186 <li><b>mech_free</b> - Called when the sasl library is shutting down
187 (by <tt>sasl_done</tt>).
188 Intended to free any global state of the plugin.</li>
190 <a name="server"><h2>Server Plugins</h2></a>
191 <p>Server-side mechanism plugins are generally included in the same
192 plugin with their <a href="#client">client</a> counterpart, though
193 this is not a requirement. They take care of the server-side of the
194 SASL negotiation, and are generally more complicated than their
195 client-side counterparts. For a simple example, see the ANONYMOUS
197 <p>Server plugins must export <tt>sasl_server_plug_init</tt> which returns
198 a <tt>sasl_server_plug_t</tt> in order to load. The structure has
199 several functional members and a global context (which applies to
200 all connections using the plugin). The important ones are described
203 <li><b>mech_new</b> - Called at the beginning of each connection,
204 (on a call to sasl_client_start),
205 mech_new does mechanism-specific initialization, and if necessary
206 allocates a connection context (which the glue code keeps track
207 of for it). mech_new does not actually send any data to the client,
208 it simply allocates the context.</li>
209 <li><b>mech_step</b> - Called from <tt>sasl_server_start</tt> and
210 <tt>sasl_server_step</tt>, this function does the actual work of
212 side of the authentication. If authentication is successful, it
213 should return SASL_OK, otherwise it should return a valid SASL
214 error code (and call seterror). This should also set up the
215 oparams structure before returning SASL_OK, including any
216 security layer information (in the way of callbacks and SSF
217 information). Also, as soon
218 as the mechanism has computed both the authentication and the
219 authorization IDs, it MUST call the canon_user function provided
220 in the server params structure (for both the authentication and
221 authorization IDs, with SASL_CU_AUTHID and SASL_CU_AUTHZID
222 respectively). This action will also fill in its
223 propctx, so any auxiliary property <i>requests</i>
224 (for example, to lookup
225 the password) should be done before the request to canonicalize
226 the authentication id. Authorization ID lookups do not occur until
227 after the plugin returns success to the SASL library.<p>
229 Before returning SASL_OK, <tt>mech_step</tt> must fill in the
230 oparams fields for which it is responsible, that is, <tt>doneflag</tt>
231 (set to 1 to indicate a complete exchange), <tt>maxoutbuf</tt>, or
232 the maximum output size it can do at once for a security layer,
233 <tt>mech_ssf</tt> or the supplied SSF of the security layer,
234 and <tt>encode</tt>, <tt>decode</tt>, <tt>encode_context</tt>,
235 and <tt>decode_context</tt>,
236 which are what the glue code will call on calls to <tt>sasl_encode</tt>,
237 <tt>sasl_encodev</tt>, and <tt>sasl_decode</tt>.</li>
238 <li><b>mech_dispose</b> - Called to dispose of a connection context.
239 This is only called when the connection will no longer be used
240 (e.g. when <tt>sasl_dispose</tt> is called)</li>
241 <li><b>mech_free</b> - Called when the sasl library is shutting down
242 (by <tt>sasl_done</tt>).
243 Intended to free any global state of the plugin.</li>
244 <li><b>setpass</b> - Called to set a user's password. This allows
245 mechanisms to support their own internal password or secret
247 <li><b>mech_avail</b> - Called by the first call to
248 <tt>sasl_listmech</tt>,
249 it checks to see if the mechanism is available for the given
250 user, and MAY allocate a connection context (thus avoiding
251 a call to <tt>mech_new</tt>). However it should not do this
252 without significant performance benefit as it forces the glue
253 code to keep track of extra contexts that may not be used.</li>
255 <a name="canon_user"><h2>User Canonicalization (canon_user) Plugins</h2></a>
256 <p>User Canonicalization plugins allow for nonstandard ways of
257 canonicalizing the username. They are subject to the following
260 <li>They must copy their output into the provided output buffers.</li>
261 <li>The output buffers may be the same as the input buffers.</li>
262 <li>They must function for the case which is only an authentication
263 ID (flags == SASL_CU_AUTHID) or only an authorization ID
264 (flags == SASL_CU_AUTHZID) or both
265 (flags == SASL_CU_AUTHID | SASL_CU_AUTHZID)
267 <p>User canonicalization plugins must export a <tt>sasl_canonuser_init</tt>
268 function which returns a <tt>sasl_canonuser_plug_t</tt> in order
269 to load successfully. They must implement at least one of
270 the <tt>canon_user_client</tt> or <tt>canon_user_server</tt> members
271 of the <tt>sasl_canonuser_plug_t</tt>. The INTERNAL canon_user plugin
272 that is inside of the glue code implements both in the same way.</p>
273 <a name="auxprop"><h2>Auxiliary Property (auxprop) Plugins</h2></a>
274 <p>Perhaps the most exciting addition in SASLv2, Auxprop plugins
275 allow for an easy way to perform password and secret lookups (as well
276 as other information needed for authentication and authorization)
277 from directory services, and in the same request allow the application
278 to receive properties that it needs to provide the service.
280 <p>Auxprop plugins need to export the <tt>sasl_auxprop_init</tt> function
281 and pass back a <tt>sasl_auxprop_plug_t</tt> in order to load
282 successfully. The sasldb plugin included with the Cyrus SASL
283 distribution would be a good place to start.</p>
284 <p>Interfacing with property contexts is extremely well documented in
285 <tt>prop.h</tt> and so that is omitted here. The only important
286 note is to be sure that you are using the interfaces provided
287 through the <tt>sasl_utils_t</tt> structure and not calling
288 the functions directly.</p>
289 <p>To successfully implement an auxprop plugin there is only one
290 required function to implement, that is the <tt>auxprop_lookup</tt>
291 member of the <tt>sasl_auxprop_plug_t</tt>. This is called
292 just after canonicalization of the username, with the canonicalized
293 username. It can then do whatever lookups are necessary for any
294 of the requested auxiliary properties.</p>
297 Back to the <A href=index.html>index</a>