mirror of https://github.com/sipwise/kamailio.git
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
148 lines
5.3 KiB
148 lines
5.3 KiB
1. Auth_radius Module
|
|
|
|
Jan Janak
|
|
|
|
FhG Fokus
|
|
<jan@iptel.org>
|
|
|
|
Juha Heinanen
|
|
|
|
Song Networks
|
|
<jh@song.fi>
|
|
|
|
Stelios Sidiroglou-Douskos
|
|
|
|
Copyright © 2002, 2003 FhG FOKUS
|
|
__________________________________________________________________
|
|
|
|
1.1. Overview
|
|
1.2. Dependencies
|
|
1.3. Parameters
|
|
|
|
1.3.1. radius_config (string)
|
|
1.3.2. service_type (integer)
|
|
1.3.3. use_ruri_flag (integer)
|
|
|
|
1.4. Functions
|
|
|
|
1.4.1. radius_www_authorize(realm)
|
|
1.4.2. radius_proxy_authorize(realm)
|
|
|
|
1.1. Overview
|
|
|
|
This module contains functions that are used to perform authentication
|
|
using a Radius server. Basically the proxy will pass along the
|
|
credentials to the radius server which will in turn send a reply
|
|
containing result of the authentication. So basically the whole
|
|
authentication is done in the Radius server. Before sending the request
|
|
to the radius server we perform some sanity checks over the credentials
|
|
to make sure that only well formed credentials will get to the server.
|
|
We have implemented radius authentication according to
|
|
draft-sterman-aaa-sip-00. This module requires radiusclient library
|
|
version 0.5.0 or higher which is available from
|
|
http://developer.berlios.de/projects/radiusclient-ng/.
|
|
|
|
1.2. Dependencies
|
|
|
|
The module depends on the following modules (in the other words the
|
|
listed modules must be loaded before this module):
|
|
* auth. Generic authentication functions.
|
|
|
|
1.3. Parameters
|
|
|
|
1.3.1. radius_config (string)
|
|
|
|
This is the location of the configuration file of radius client
|
|
libraries.
|
|
|
|
Default value is "/usr/local/etc/radiusclient/radiusclient.conf".
|
|
|
|
Example 1. radius_config parameter usage
|
|
modparam("auth_radius", "radius_config", "/etc/radiusclient.conf")
|
|
|
|
1.3.2. service_type (integer)
|
|
|
|
This is the value of the Service-Type radius attribute to be used. The
|
|
default should be fine for most people. See your radius client include
|
|
files for numbers to be put in this parameter if you need to change it.
|
|
|
|
Default value is "15".
|
|
|
|
Example 2. service_type usage
|
|
modparam("auth_radius", "service_type", 15)
|
|
|
|
1.3.3. use_ruri_flag (integer)
|
|
|
|
When this parameter is set to the value other than "-1" and the request
|
|
being authenticated has flag with matching number set via setflag()
|
|
function, use Request URI instead of uri parameter value from the
|
|
Authorization / Proxy-Authorization header field to perform RADIUS
|
|
authentication. This is intended to provide workaround for misbehaving
|
|
NAT / routers / ALGs that alter request in the transit, breaking
|
|
authentication. At the time of this writing, certain versions of
|
|
Linksys WRT54GL are known to do that.
|
|
|
|
Default value is "-1".
|
|
|
|
Example 3. use_ruri_flag usage
|
|
modparam("auth_radius", "use_ruri_flag", 22)
|
|
|
|
1.4. Functions
|
|
|
|
1.4.1. radius_www_authorize(realm)
|
|
|
|
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.
|
|
|
|
This function will, in fact, perform sanity checks over the received
|
|
credentials and then pass them along to the radius server which will
|
|
verify the credentials and return whether they are valid or not.
|
|
|
|
Meaning of the parameter 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.
|
|
|
|
Example 4. radius_www_authorize usage
|
|
...
|
|
if (!radius_www_authorize("iptel.org")) {
|
|
www_challenge("iptel.org", "1");
|
|
};
|
|
...
|
|
|
|
1.4.2. radius_proxy_authorize(realm)
|
|
|
|
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.
|
|
|
|
This function will, in fact, perform sanity checks over the received
|
|
credentials and then pass them along to the radius server which will
|
|
verify the credentials and return whether they are valid or not.
|
|
|
|
Meaning of the parameter 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.
|
|
|
|
Example 5. proxy_authorize usage
|
|
...
|
|
if (!radius_proxy_authorize("")) {
|
|
proxy_challenge("", "1"); # Realm will be autogenerated
|
|
};
|
|
...
|