doc/plugprog.html

   1 <HTML><HEAD>
   2 <title>SASL Plugin Programmer's Guide</title>
   3 <!-- $Id: plugprog.html,v 1.5 2002/05/07 15:13:45 ken3 Exp $ -->
   4 </HEAD>
   5 <BODY>
   6 <h1>SASL Plugin Programmer's Guide</h1>
   7
   8 <h3>NOTE: This is a work in progress. Any contributions would be
   9 <i>very</i> appreciated</h3>
  10
  11 <ul><h2>Contents</h2>
  12   <li><a href="#intro">Introduction</a></li>
  13   <ul>
  14     <li><a href="#about_this_guide">About this Guide</A></li>
  15     <li><a href="#about_sasl">What is SASL</A></li>
  16   </ul>
  17   <li><a href="#common">Common Section</a></li>
  18   <ul>
  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>
  24   </ul>
  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>
  29 </ul>
  30
  31 <a name="intro"><h2>Introduction</h2></a>
  32
  33     <a name="about_this_guide"><h3>About this Guide</h3></a>
  34
  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
  44         </i></a>.</p>
  45
  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.
  49     </p>
  50
  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.
  56     </p>
  57
  58 <a name="common"><h2>Common Section</h2></a>
  59     <a name="overview"><h3>Overview of Plugin Programming</h3></a>
  60
  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
  66        of .so as well.</p>
  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>
  78     <ul>
  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>
  88     </ul>
  89
  90     <a name="sasl_utils_t"><h3>Use of sasl_utils_t</h3></a>
  91
  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>
 103
 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>
 114
 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>
 121
 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
 131       follows:</p>
 132     <ul>
 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>
 137     </ul>
 138
 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.
 145
 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.
 152
 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
 162        briefly here.</p>
 163     <ul>
 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
 172         the client
 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
 182         respectively).</li>
 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>
 189     </ul>
 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
 196        plugin.</p>
 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
 201        briefly here.</p>
 202     <ul>
 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
 211         the server
 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>
 228
 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
 246         database.</li>
 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>
 254     </ul>
 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
 258        requirements:</p>
 259     <ul>
 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)
 266     </ul>
 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.
 279     </p>
 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>
 295 </p>
 296 <hr>
 297 Back to the <A href=index.html>index</a>
 298
 299 </body>
 300 </html>