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:
-->
|