Auth_aaa Module

The module depends on the following modules (in the other words the listed modules must be loaded before this module):

This module does not depend on any external library.

This is the url representing the AAA protocol used and the location of the configuration file of this protocol.

The syntax for the url is the following: "name_of_the_aaa_protocol_used:path_of_the_configuration_file"

		
modparam("auth_aaa", "aaa_url", "radius:/etc/radiusclient-ng/radiusclient.conf")
		

This is the value of the Service-Type aaa attribute to be used when performing an authentication operation. The default should be fine for most people. See your aaa client include files for numbers to be put in this parameter if you need to change it.

Default value is “15”.

		
modparam("auth_aaa", "auth_service_type", 15)
		

AAA service type used by aaa_does_uri_exist and aaa_does_uri_user_exist checks.

Default value is 10 (Call-Check).

...
modparam("auth_aaa", "check_service_type", 11)
...

When this parameter is set to the value other than "NULL" 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 AAA 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 “NULL” (not set).

		
modparam("auth_aaa", "use_ruri_flag", "USE_RURI_FLAG")
		

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:

This function will, in fact, perform sanity checks over the received credentials and then pass them along to the aaa server which will verify the credentials and return whether they are valid or not.

Meaning of the parameter is as follows:

This function can be used from REQUEST_ROUTE.

		
...
if (!aaa_www_authorize("siphub.net"))
	www_challenge("siphub.net", "auth");
...

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. For more about the negative return codes, see the above function.

This function will, in fact, perform sanity checks over the received credentials and then pass them along to the aaa server which will verify the credentials and return whether they are valid or not.

Meaning of the parameters is as follows:

This function can be used from REQUEST_ROUTE.

		
...
if (!aaa_proxy_authorize(""))    # Realm and URI user will be autogenerated
	proxy_challenge("", "auth");
...
if (!aaa_proxy_authorize($pd, $pU))    # Realm and URI user are taken
	proxy_challenge($pd, "auth");  # from P-Preferred-Identity
                                       # header field
...

Checks from Radius if the SIP URI stored in the "sip_uri" parameter (or user@host part of the Request-URI if "sip_uri" is not given) belongs to a local user. Can be used to decide if 404 or 480 should be returned after lookup has failed. If yes, loads AVP based on SIP-AVP reply items returned from Radius. Each SIP-AVP reply item must have a string value of form:

Returns 1 if Radius returns Access-Accept, -1 if Radius returns Access-Reject, and -2 in case of internal error.

This function can be used from REQUEST_ROUTE.

...
if (aaa_does_uri_exist()) {
	...
};
...

Similar to aaa_does_uri_exist, but check is done based only on Request-URI user part or user stored in "sip_uri". The user should thus be unique among all users, such as an E.164 number.

This function can be used from REQUEST_ROUTE.

...
if (aaa_does_uri_user_exist()) {
	...
};
...