Published on iptel.org (http://www.iptel.org)

auth

By greger
Created 2006-11-26 09:08

Standard

This is a generic module that itself doesn't provide all functions necessary for authentication but provides functions that are needed by all other authentication related modules (so called authentication backends).

We decided to break the authentication code into several modules because there are now more than one backends (currently database authentication and radius are supported). This allows us to create separate packages so uses can install and load only required functionality. This also allows us to avoid unnecessary dependencies in the binary packages.


Jan Janak
Juha Heinanen


jan@iptel.org [1]>

Juha Heinanen

Song Networks
Revision History
Revision $Revision: 1.3 $ $Date: 2005/08/24 22:26:17 $

i [3] replies.

i [4] returned from either radius or database.

Default value is "" (empty string).

RFC2617 [5].

Meaning of the parameters is as follows:

  • realm - 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.

    If an empty string "" 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.

  • qop - Value of this parameter can be either "1" or "0". When set to 1 then the server will put qop parameter in the challenge. When set to 0 then the server will not put qop parameter in the challenge. It is strongly recommended to use qop parameter, however there are still some user agents that cannot handle qop parameter properly so we made this optional. On the other hand there are still some user agents that cannot handle request without qop parameter too.

RFC2617 [6].

Meaning of the parameters is as follows:

  • realm - 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.

    If an empty string "" is used then the server will generate it from the request. From header field domain will be used as realm.

  • qop - Value of this parameter can be either "1" or "0". When set to 1 then the server will put qop parameter in the challenge. When set to 0 then the server will not put qop parameter in the challenge. It is strongly recommended to use qop parameter, however there are still some user agents that cannot handle qop parameter properly so we made this optional. On the other hand there are still some user agents that cannot handle request without qop parameter too.

i [7] message will not contain credentials there were used by this server. This ensures that the proxy will not reveal information about credentials used to downstream elements and also the message will be a little bit shorter. The function must be called after www_authorize or proxy_authorize.

Section 1.4.5, “append_rpid_hf()” [8]. The only difference is that it accepts two parameters, prefix and suffix to be added to Remote-Party-ID header field. This function ignores rpid_prefix and rpid_suffix parameters, instead of that allows to set them for every call.

Meaning of the parameters is as follows:

  • prefix - Prefix of the Remote-Party-ID URI. The string will be added at the begining of body of the header field, just before the URI.

  • suffix - Suffix of the Remote-Party-ID header field. The string will be appended at the end of the header field. It can be used to set various URI parameters, for example.

Example 10. append_rpid_hf(prefix, suffix) usage

...
append_rpid_hf("", ";party=calling;id-type=subscriber;screen=yes");  # Append Remote-Party-ID header field
...