1<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> 2 3<html> 4 <head> 5 <meta name="generator" content="HTML Tidy, see www.w3.org"> 6 <title>Adding Authentication Support</title> 7 <meta name="GENERATOR" content= 8 "Modular DocBook HTML Stylesheet Version 1.7"> 9 <link rel="HOME" title=" LPRng Reference Manual" href= 10 "index.htm"> 11 <link rel="UP" title="Permissions and Authentication " href= 12 "permsref.htm"> 13 <link rel="PREVIOUS" title="Using MD5 for Authentication" href= 14 "x9489.htm"> 15 <link rel="NEXT" title="Accounting " href="accountingref.htm"> 16 </head> 17 18 <body class="SECT1" bgcolor="#FFFFFF" text="#000000" link= 19 "#0000FF" vlink="#840084" alink="#0000FF"> 20 <div class="NAVHEADER"> 21 <table summary="Header navigation table" width="100%" border= 22 "0" cellpadding="0" cellspacing="0"> 23 <tr> 24 <th colspan="3" align="center">LPRng Reference Manual: 5 25 Sep 2003 (For LPRng-3.8.22)</th> 26 </tr> 27 28 <tr> 29 <td width="10%" align="left" valign="bottom"><a href= 30 "x9489.htm" accesskey="P">Prev</a></td> 31 32 <td width="80%" align="center" valign="bottom">Chapter 33 17. Permissions and Authentication</td> 34 35 <td width="10%" align="right" valign="bottom"><a href= 36 "accountingref.htm" accesskey="N">Next</a></td> 37 </tr> 38 </table> 39 <hr align="LEFT" width="100%"> 40 </div> 41 42 <div class="SECT1"> 43 <h1 class="SECT1"><a name="AEN9556">17.17. Adding 44 Authentication Support</a></h1> 45 46 <p>Additional types of authentication support can be added 47 very easily to <b class="APPLICATION">LPRng</b> by using the 48 following conventions and guidelines.</p> 49 50 <p>First, the authentication method can be connection based 51 or transfer based. Connection based authentication involves 52 the <b class="APPLICATION">LPRng</b> client or server opening 53 a connection to the remote server, having the authentication 54 protocol provide authentication information, and then having 55 no further interaction with the system. This is the easiest 56 to implement and understand method. Code needs to be provided 57 to do a simple authentication exchange between the two ends 58 of the connection, after which no other action needs to be 59 taken.</p> 60 61 <p>Transfer based authentication is more complex, but allows 62 encrypted transfers of information between the two systems. A 63 connection is established between client and server (or 64 server and server), and an initial protocol exchange is 65 performed. Then the authentication module transfers the 66 command or job information to the destination, where is it 67 unpacked and/or decrypted. The internal <b class= 68 "APPLICATION">lpd</b> server facilities are then invoked by 69 the authentication module, which also provides a destination 70 for any error message or information destined for the client. 71 The authentication module will encrypt or encode this 72 information and then send it to the client program. This type 73 of authentication is more complex, but provides a higher 74 degree of security and reliability than the simple connection 75 based system.</p> 76 77 <div class="SECT2"> 78 <h2 class="SECT2"><a name="AEN9564">17.17.1. Printcap 79 Support</a></h2> 80 81 <p>By convention, printcap entries <var class= 82 "LITERAL">auth=XXX</var> and <var class= 83 "LITERAL">auth_forward=XXX</var> specifies that 84 authentication protocol <acronym class= 85 "ACRONYM">XXX</acronym> is to be used for client to server 86 and for server to server transfers respectively.</p> 87 88 <p>Similarly, the server receiving an authentication 89 request must have a <var class="LITERAL">XXX_id=name</var> 90 entry in the printcap or configuration information. This 91 allows several different authentication protocols to be 92 accepted by a server.</p> 93 94 <p>By convention, printcap and configuration entries of the 95 form <var class="LITERAL">XXX_key</var> contain 96 configuration information for the <acronym class= 97 "ACRONYM">XXX</acronym> authentication protocol. As part of 98 the authentication support process the <var class= 99 "LITERAL">XXX_key</var> values are extracted from the 100 printcap and configuration files and placed in a simple 101 database for the authentication support module.</p> 102 103 <p>If you are using a routing filter, then you can also 104 place <var class="LITERAL">XXX_key</var> information in the 105 routing entry for each file, and this will be used for 106 sending the job to the specified destination.</p> 107 </div> 108 109 <div class="SECT2"> 110 <h2 class="SECT2"><a name="AEN9578">17.17.2. Code 111 Support</a></h2> 112 113 <p>The <tt class= 114 "FILENAME">LPRng/src/common/sendauth.c</tt> file has the 115 following entries at the end.</p> 116 117 <div class="INFORMALEXAMPLE"> 118 <a name="AEN9582"></a> 119<pre class="SCREEN"> 120 #define SENDING 121 #include "user_auth.stub" 122 123 struct security SendSecuritySupported[] = { 124 /* name, config_tag, connect, send, receive */ 125 { "kerberos4", "kerberos", Send_krb4_auth, 0, 0 }, 126 { "kerberos*", "kerberos", 0, Krb5_send }, 127 { "pgp", "pgp", 0, Pgp_send }, 128 #if defined(USER_SEND) 129 USER_SEND 130 #endif 131 {0} 132 }; 133</pre> 134 </div> 135 This is an example of how to add user level authentication 136 support. The <tt class="FILENAME">user_auth.stub</tt> file 137 contains the source code for the various modules 138 authentication modules. You can replace this file with your 139 own version if desired. The following fields are used. 140 141 <div class="VARIABLELIST"> 142 <dl> 143 <dt>name</dt> 144 145 <dd> 146 <p>The authentication name. The <var class= 147 "LITERAL">auth=XXX</var> printcap or configuration 148 value will cause the <var class="LITERAL">name</var> 149 fields to be searched using a glob match.</p> 150 </dd> 151 152 <dt>config_tag</dt> 153 154 <dd> 155 <p>When a match is found, the <var class= 156 "LITERAL">config_tag</var> value is used to search 157 the printcap and configuration entries for 158 information. If the <var class= 159 "LITERAL">config_tag</var> field has value <acronym 160 class="ACRONYM">XXX</acronym>, then entries with keys 161 <var class="LITERAL">XXX_key</var> will be extracted 162 for use by the authentication code.</p> 163 </dd> 164 165 <dt>connect</dt> 166 167 <dd> 168 <p>Routine to call to support <var class= 169 "LITERAL">connection</var> level authentication. This 170 routine is responsible for connection establishment 171 and protocol handshake. If the value is 0, then the 172 <var class="LITERAL">send</var> field value will be 173 used.</p> 174 </dd> 175 176 <dt>send</dt> 177 178 <dd> 179 <p>Routine to call to support <var class= 180 "LITERAL">transfer</var> level authentication. The 181 <var class="LITERAL">send</var> routine is provided a 182 file and a connection to the remote server, and is 183 responsible for the transferring files.</p> 184 </dd> 185 </dl> 186 </div> 187 <br> 188 <br> 189 190 <p>The <tt class= 191 "FILENAME">LPRng/src/common/lpd_secure.c</tt> file has the 192 following information at the end:</p> 193 194 <div class="INFORMALEXAMPLE"> 195 <a name="AEN9614"></a> 196<pre class="SCREEN"> 197 #define RECEIVE 1 198 #include "user_auth.stub" 199 200 struct security ReceiveSecuritySupported[] = { 201 /* name, config_tag, connect, send, receive */ 202 #if defined(HAVE_KRB_H) && defined(MIT_KERBEROS4) 203 { "kerberos4", "kerberos", 0, 0, 0 }, 204 #endif 205 #if defined(HAVE_KRB5_H) 206 { "kerberos*", "kerberos", 0, 0, Krb5_receive }, 207 #endif 208 { "pgp", "pgp", 0, 0, Pgp_receive, }, 209 #if defined(USER_RECEIVE) 210 /* this should have the form of the entries above */ 211 USER_RECEIVE 212 #endif 213 {0} 214 }; 215</pre> 216 </div> 217 <br> 218 <br> 219 220 <p>This information matches the same information in the <tt 221 class="FILENAME">sendauth.c</tt> file. When the 222 authentication request arrives at the server, the <var 223 class="LITERAL">name</var> field values are searched for a 224 match, and then the <var class="LITERAL">config_tag</var> 225 value is used to get extract configuration information from 226 the database for the protocol.</p> 227 228 <p>The <var class="LITERAL">receive</var> routine is then 229 called and is expected to handle the remaining steps of the 230 authentication protocol. If the routine exits with a 0 231 value then the lpd server expects <var class= 232 "LITERAL">connection</var> level authentication has been 233 done and proceeds to simply transfer information using the 234 standard RFC1179 protocol steps. A non-zero return value 235 indicates an error and an error is reported to the other 236 end of the connection.</p> 237 238 <p>If the <var class="LITERAL">receive</var> module is to 239 perform <var class="LITERAL">transfer</var> level 240 authentication, then the module carries out the necessary 241 steps to transfer the command and/or job information. It 242 then calls the necessary internal <b class= 243 "APPLICATION">LPRng</b> routine to implement the desired 244 services. After finishing the requested work, these 245 routines return to the calling authentication module, which 246 then will transfer data, close the connection to the remote 247 system, and return to the calling system. The combination 248 of 0 return value and closed connection indicates 249 successful transfer level authentication to the server.</p> 250 251 <p>The <tt class="FILENAME">user_auth.stub</tt> file 252 contains the following code that sets the <var class= 253 "LITERAL">USER_SEND</var> variable:</p> 254 255 <div class="INFORMALEXAMPLE"> 256 <a name="AEN9630"></a> 257<pre class="SCREEN"> 258 #if defined(SENDING) 259 extern int md5_send(); 260 # define USER_SEND \ 261 { "md5", "md5", md5_send, 0, md5_receive }, 262 #endif 263</pre> 264 </div> 265 <br> 266 <br> 267 268 <p>If the <acronym class="ACRONYM">SENDING</acronym> value 269 has been defined, this causes the prototype for <code 270 class="FUNCTION">md5_send()</code> to be place in the file 271 and the <var class="LITERAL">USER_SEND</var> value to be 272 defined. This will cause the <var class="LITERAL">md5</var> 273 authentication information to be placed in the correct 274 table.</p> 275 </div> 276 277 <div class="SECT2"> 278 <h2 class="SECT2"><a name="AEN9637">17.17.3. Connection and 279 Transfer Authentication</a></h2> 280 281 <p>Rather than go into a detailed description of the code, 282 the <tt class="FILENAME">user_auth.stub</tt> file contains 283 extremely detailed examples as well as several working 284 versions of authentication information. It is recommended 285 that the user start with one of these and then modify it to 286 suit themselves.</p> 287 </div> 288 </div> 289 290 <div class="NAVFOOTER"> 291 <hr align="LEFT" width="100%"> 292 293 <table summary="Footer navigation table" width="100%" border= 294 "0" cellpadding="0" cellspacing="0"> 295 <tr> 296 <td width="33%" align="left" valign="top"><a href= 297 "x9489.htm" accesskey="P">Prev</a></td> 298 299 <td width="34%" align="center" valign="top"><a href= 300 "index.htm" accesskey="H">Home</a></td> 301 302 <td width="33%" align="right" valign="top"><a href= 303 "accountingref.htm" accesskey="N">Next</a></td> 304 </tr> 305 306 <tr> 307 <td width="33%" align="left" valign="top">Using MD5 for 308 Authentication</td> 309 310 <td width="34%" align="center" valign="top"><a href= 311 "permsref.htm" accesskey="U">Up</a></td> 312 313 <td width="33%" align="right" valign="top"> 314 Accounting</td> 315 </tr> 316 </table> 317 </div> 318 </body> 319</html> 320 321