Table of Contents
name (string)
auth_data_hash_size (integer)
auth_vector_timeout (integer)
auth_data_timeout (int)
av_request_at_once (integer)
av_request_at_sync (integer)
registration_default_algorithm
(string)
registration_qop (string)
cxdx_forced_peer (string)
cxdx_dest_realm (string)
List of Examples
name parameter usageauth_data_hash_size parameter usageauth_vector_timeout parameter usagepassword_column parameter usageav_request_at_once parameter usageav_request_at_sync parameter usageregistration_default_algorithm parameter
usageload_credentials parameter usagecxdx_forced_peer parameter usageversion_table parameter usagewww_authorize
usageTable of Contents
name (string)
auth_data_hash_size (integer)
auth_vector_timeout (integer)
auth_data_timeout (int)
av_request_at_once (integer)
av_request_at_sync (integer)
registration_default_algorithm
(string)
registration_qop (string)
cxdx_forced_peer (string)
cxdx_dest_realm (string)
This module contains all authentication related functions for an IMS environment. The module does not depend on the base Kamailio auth modules as other auth modules do. Instead ims_auth is dependent on the CDP (C Diameter Peer) modules for communicating with HSS as specified in 3GPP specs.
The Following mouldes must be loaded before this module:
TM - Transaction Manager
CDP - C Diameter Peer
CDP_AVP - CDP AVP Applications
This is the name of the SCSCF as identified in communication with the HSS (Server-Name AVP of MAR).
Default value is 'sip:scscf.ims.smilecoms.com:6060'.
Example 1.1. name parameter usage
...
modparam("ims_auth", "name", "sip:scscf3.ims.smilecoms.com:6060")
...
This is the size of the hash table used to store auth vectors (AV). Default value is fine for most people. Use the parameter if you really need to change it.
Default value is “1024”.
Example 1.2. auth_data_hash_size parameter usage
...
modparam("ims_auth", "auth_data_hash_size", 1024)
...
This is the time, in seconds, that a SENTauth vector is valid for. If there is no response ...
Default value is “60”.
Example 1.3. auth_vector_timeout parameter usage
...
modparam("ims_auth", "auth_vector_timeout", "domain")
...
Time, in seconds, an used auth vector is valid for.
Default value is “60”.
How many auth vectors to request in MAR.
Default value is 1
Example 1.5. av_request_at_once parameter usage
...
modparam("ims_auth", "av_request_at_once", 1)
...
How many auth vectors to request at sync. Default value is 1.
Example 1.6. av_request_at_sync parameter usage
...
modparam("ims_auth", "av_request_at_sync", 1)
...
The default authentication algorithm to use for registration if one is not specified.
Options are:
AKAV1-MD5
AKAV2-MD5
MD5
HSS-Selected - HSS will decide on auth algorithm
Default value is “AKAv1-MD5”.
Example 1.7. registration_default_algorithm parameter
usage
...
modparam("ims_auth", "registration_default_algorithm", "HSS-Selected")
...
The QOP options to put in the authorisation challenges.
Default value of this parameter is “auth,auth-int”.
Example 1.8. load_credentials parameter usage
...
modparam("ims_auth", "load_credentials", "auth-int")
...
The function verifies credentials according to RFC2617. 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
www_challenge which will challenge
the user again.
Negative codes may be interpreted as follows:
-1 (generic error) - some generic error occurred and no reply was sent out;
-2 (invalid password) - valid user, but wrong password;
-3 (invalid user) - authentication user does not exist.
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.
It must not be empty string “”. In case of REGISTER requests To header field domain (e.g., variable $td) can be used (because this header field represents the user being registered), for all other messages From header field domain can be used (e.g., variable $fd).
The string may contain pseudo variables.
table - Table to be used to lookup usernames and passwords (usually subscribers table).
This function can be used from REQUEST_ROUTE.
Example 1.11. www_authorize
usage
...
if (!www_authorize("kamailio.org", "subscriber")) {
www_challenge("kamailio.org", "1");
};
...
It is same function as www_authenticate(realm, table). This name is kept for backward compatibility, since it was named this way first time by it actually does user authentication.
Name alias: proxy_authorize(realm, table)
The function verifies credentials according to RFC2617. 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
proxy_challenge which will
challenge the user again.
Negative return codes have the same meaning as for www_authenticate().
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.
It must not be empty string “”. Apart of a static strinh, typical value is From header field domain (e.g., variable $fd).
If an empty string “” is used then the server will generate it from the request. From header field domain will be used as realm.
The string may contain pseudo variables.
table - Table to be used to lookup usernames and passwords (usually subscribers table).
This function can be used from REQUEST_ROUTE.
Example 1.12. proxy_authorize usage
...
if (!proxy_authorize("$fd", "subscriber)) {
proxy_challenge("$fd", "1"); # Realm will be autogenerated
};
...
Name alias: proxy_authorize(realm, table)
The function verifies credentials according to RFC2617. 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
proxy_challenge which will
challenge the user again.
Negative return codes have the same meaning as for www_authenticate().
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.
It must not be empty string “”. Apart of a static strinh, typical value is From header field domain (e.g., variable $fd).
If an empty string “” is used then the server will generate it from the request. From header field domain will be used as realm.
The string may contain pseudo variables.
table - Table to be used to lookup usernames and passwords (usually subscribers table).
This function can be used from REQUEST_ROUTE.
Example 1.13. proxy_authorize usage
...
if (!proxy_authorize("$fd", "subscriber)) {
proxy_challenge("$fd", "1"); # Realm will be autogenerated
};
...