File: auth_db_user.sgml

package info (click to toggle)
openser 1.1.0-9etch1
  • links: PTS
  • area: main
  • in suites: etch, etch-m68k
  • size: 9,828 kB
  • ctags: 11,809
  • sloc: ansic: 120,528; sh: 5,249; yacc: 1,716; makefile: 1,261; php: 656; perl: 205; sql: 190
file content (372 lines) | stat: -rw-r--r-- 12,090 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
<!-- Auth_db Module User's Guide -->

<chapter>
	<chapterinfo>
	<revhistory>
		<revision>
		<revnumber>$Revision: 1.5 $</revnumber>
		<date>$Date: 2006/05/22 14:55:28 $</date>
		</revision>
	</revhistory>
	</chapterinfo>
	<title>User's Guide</title>
	
	<section>
	<title>Overview</title>
	<para>
		This module contains all authentication related functions that need 
		the access to the database. This module should be used together with 
		auth module, it cannot be used independently because it depends on 
		the module. Select this module if you want to use database to store 
		authentication information like subscriber usernames and passwords. If
		you want to use radius authentication, then use auth_radius instead.
	</para>
	</section>

	<section>
		<title>Dependencies</title>
		<section>
			<title>&ser; Modules</title>
			<para>
			The module depends on the following modules (in the other words 
			the listed modules must be loaded before this module):
			<itemizedlist>
			<listitem>
				<para><emphasis>auth</emphasis> -- Generic authentication 
				functions
				</para>
			</listitem>
			<listitem>
				<para><emphasis>database</emphasis> -- Any database module
				(currently mysql, postgres, dbtext)
				</para>
			</listitem>
			</itemizedlist>
		</para>
		</section>
		<section>
			<title>External Libraries or Applications</title>
			<para>
			The following libraries or applications must be installed 
			before running &ser; with this module loaded:
			<itemizedlist>
				<listitem>
				<para><emphasis>none</emphasis></para>
				</listitem>
			</itemizedlist>
		</section>
	</section>


	<section>
	<title>Exported Parameters</title>
	<section>
		<title><varname>db_url</varname> (string)</title>
		<para>
		This is URL of the database to be used. Value of the parameter depends 
		on the database module used. For example for mysql and postgres modules 
		this is something like mysql://username:password@host:port/database. 
		For dbtext module (which stores data in plaintext files) it is directory 
		in which the database resides.
		</para>
		<para>
		Default value is
			<quote>mysql://openserro:openserro@localhost/openser</quote>.
		</para>
		<example>
		<title><varname>db_url</varname> parameter usage</title>
		<programlisting format="linespecific">
modparam("auth_db", "db_url", "mysql://foo:bar@foobar.org/openser")
</programlisting>
		</example>
	</section>

	<section>
		<title><varname>user_column</varname> (string)</title>
		<para>
		This is the name of the column holding usernames. Default value is 
		fine for most people. Use the parameter if you really need to change it.
		</para>
		<para>
		Default value is <quote>username</quote>.
		</para>
		<example>
		<title><varname>user_column</varname> parameter usage</title>
		<programlisting format="linespecific">
modparam("auth_db", "user_column", "user")
</programlisting>
		</example>
	</section>

	<section>
		<title><varname>domain_column</varname> (string)</title>
		<para>
		This is the name of the column holding domains of users. Default value 
		is fine for most people. Use the parameter if you really need to 
		change it.
		</para>
		<para>
		Default value is <quote>domain</quote>.
		</para>
		<example>
		<title><varname>domain_column</varname> parameter usage</title>
		<programlisting format="linespecific">
modparam("auth_db", "domain_column", "domain")
</programlisting>
		</example>
	</section>

	<section>
		<title><varname>password_column</varname> (string)</title>
		<para>
		This is the name of the column holding passwords. Passwords can be 
		either stored as plain text or pre-calculated HA1 strings. HA1 strings 
		are MD5 hashes of username, password, and realm. HA1 strings are more 
		safe because the server doesn't need to know plaintext passwords and 
		they cannot be obtained from HA1 strings.
		</para>
		<para>
		Default value is <quote>ha1</quote>.
		</para>
		<example>
		<title><varname>password_column</varname> parameter usage</title>
		<programlisting format="linespecific">
modparam("auth_db", "password_column", "password")
</programlisting>
		</example>
	</section>

	<section>
		<title><varname>password_column_2</varname> (string)</title>
		<para>
		As described in the previous section this parameter contains name of 
		column holding pre-calculated HA1 string that were calculated including 
		the domain in the username. This parameter is used only when 
		<varname>calculate_ha1</varname> is set to 0 and user agent send a 
		credentials containing the domain in the username.
		</para>
		<para>
		Default value of the parameter is ha1b.
		</para>
		<example>
		<title><varname>password_column_2</varname> parameter usage</title>
		<programlisting format="linespecific">
modparam("auth_db", "password_column_2", "ha1_2")
</programlisting>
		</example>
	</section>

	<section>
		<title><varname>calculate_ha1</varname> (integer)</title>
		<para>
		This parameter tells server whether it should expect plaintext 
		passwords in the database or HA1 string. If the parameter is set to 1 
		then the server will assume that the column pointed to by 
		<varname>password_column</varname> contains plaintext
		passwords and it will calculate HA1 strings on the fly.
		</para>
		<para>
		If the parameter is set to 0 then the server assumes that the database 
		contains HA1 strings directly and will not calculate them. If username 
		parameter of credentials contains also @domain (some user agents put 
		domain in username parameter), then column pointed to by 
		<varname>password_column_2</varname> parameter will be used
		instead. This column should also contain HA1 strings but they should 
		be calculated including the domain in the username parameter 
		(as opposed to <varname>password_column</varname> which (when 
		containing HA1 strings) should always contains HA1 strings calculated 
		without domain in username.
		</para>
		<para>
		This ensures that the authentication will always work when using 
		pre-calculated HA1 string, not depending on the presence of the 
		domain in username.
		</para>
		<para>
		Default value of this parameter is 0.
		</para>
		<example>
		<title><varname>calculate_ha1</varname> parameter usage</title>
		<programlisting format="linespecific">
modparam("auth_db", "calculate_ha1", 1)
</programlisting>
		</example>
	</section>

	<section>
		<title><varname>use_domain</varname> (integer)</title>
		<para>
		If true (not 0), domain will be also used when looking up in the 
		subscriber table. If you have a multi-domain setup, it is strongly
		recommended to turn on this parameter to avoid username overlapping
		between domains.
		</para>
		<para>
		IMPORTANT: before turning on this parameter, be sure that the 
		<varname>domain</varname> column in <varname>subscriber</varname> 
		table is properly populated.
		</para>
		<para>
		Default value is <quote>0 (false)</quote>.
		</para>
		<example>
		<title><varname>use_domain</varname> parameter usage</title>
		<programlisting format="linespecific">
modparam("auth_db", "use_domain", 1)
		</programlisting>
		</example>
	</section>

	<section>
		<title><varname>load_credentials</varname> (string)</title>
		<para>
		This parameter specifies of credentials to be fetch from database when
		the authentication is performed. The loaded credentials will be stored
		in AVPs. If the AVP name is not specificaly given, it will be used a
		NAME AVP with the same name as the column name.
		</para>
		<para>
		 Parameter syntax:
		<itemizedlist>
			<listitem><para><emphasis>
			load_credentials = credential (';' credential)*
			</emphasis></para></listitem>
			<listitem><para><emphasis>
			credential = (avp_specification '=' column_name) |
							(column_name)
			</emphasis></para></listitem>
			<listitem><para><emphasis>
			avp_specification = 'i:'ID | 's:'NAME | alias
			</emphasis></para></listitem>
		</itemizedlist>
		</para>
		<para>
		Default value of this parameter is <quote>rpid</quote>.
		</para>
		<example>
		<title><varname>load_credentials</varname> parameter usage</title>
		<programlisting format="linespecific">
# load rpid column into i:13 AVP and email_address column
# into email_address string AVP
modparam("auth_db", "load_credentials", "i:13=rpid;email_address")
</programlisting>
		</example>
	</section>
	</section>

	<section>
	<title>Exported Functions</title>
	<section>
		<title>
			<function moreinfo="none">www_authorize(realm, table)</function>
		</title>
		<para>
		The function verifies credentials according to 
		<ulink url="http://www.ietf.org/rfc/rfc2617.txt">RFC2617</ulink>. If the 
		credentials are verified successfully then the function will succeed 
		and mark the credentials as authorized (marked credentials can be later 
		used by some other functions). If the function was unable to verify the 
		credentials for some reason then it will fail and the script should 
		call <function moreinfo="none">www_challenge</function> which will 
		challenge the user again.
		</para>
		<para>Meaning of the parameters is as follows:</para>
		<itemizedlist>
		<listitem>
			<para><emphasis>realm</emphasis> - Realm is a opaque string that 
			the user agent should present to the user so he can decide what 
			username and password to use. Usually this is domain of the host 
			the server is running on.
			</para>
			<para>
			If an empty string <quote></quote> is used then the server will 
			generate it from the request. In case of REGISTER requests To 
			header field domain will be used (because this header field 
			represents a user being registered), for all other messages From 
			header field domain will be used.
			</para>
			<para>
			The string may contain pseudo variables.
			</para>
		</listitem>
		<listitem>
			<para><emphasis>table</emphasis> - Table to be used to lookup 
			usernames and passwords (usually subscribers table).
			</para>
		</listitem>
		</itemizedlist>
		<para>
		This function can be used from REQUEST_ROUTE.
		</para>
		<example>
		<title><function moreinfo="none">www_authorize</function> usage</title>
		<programlisting format="linespecific">
...
if (www_authorize("siphub.net", "subscriber")) {
	www_challenge("siphub.net", "1");
};
...
</programlisting>
		</example>
	</section>

	<section>
		<title>
			<function moreinfo="none">proxy_authorize(realm, table)</function>
		</title>
		<para>
		The function verifies credentials according to 
		<ulink url="http://www.ietf.org/rfc/rfc2617.txt">RFC2617</ulink>. If 
		the credentials are verified successfully then the function will 
		succeed and mark the credentials as authorized (marked credentials can 
		be later used by some other functions). If the function was unable to 
		verify the credentials for some reason then it will fail and
		the script should call 
		<function moreinfo="none">proxy_challenge</function> which will
		challenge the user again.
		</para>
		<para>Meaning of the parameters is as follows:</para>
		<itemizedlist>
		<listitem>
			<para><emphasis>realm</emphasis> - Realm is a opaque string that 
			the user agent should present to the user so he can decide what 
			username and password to use. Usually this is domain of the host 
			the server is running on.
			</para>
			<para>
			If an empty string <quote></quote> is used then the server will 
			generate it from the request. From header field domain will be 
			used as realm.
			</para>
			<para>
			The string may contain pseudo variables.
			</para>
		</listitem>
		<listitem>
			<para><emphasis>table</emphasis> - Table to be used to lookup 
			usernames and passwords (usually subscribers table).
			</para>
		</listitem>
		</itemizedlist>
		<para>
		This function can be used from REQUEST_ROUTE.
		</para>
		<example>
		<title>proxy_authorize usage</title>
		<programlisting format="linespecific">
...
if (!proxy_authorize("", "subscriber)) {
	proxy_challenge("", "1");  # Realm will be autogenerated
};
...
</programlisting>
		</example>
	</section>
	</section>
</chapter>

<!-- Keep this element at the end of the file
Local Variables:
sgml-parent-document: ("auth_db.sgml" "Book" "chapter")
End:
-->