[Serusers] Help with authorization

Daniel-Constantin Mierla daniel at voice-system.ro
Fri Apr 22 16:57:31 CEST 2005



On 04/22/05 16:16, Steve Blair wrote:

>
>
> Jan Janak wrote:
>
>> On 21-04 21:08, Steve Blair wrote:
>>  
>>
>>> I have a working 0.9.1 config to which I would like add server side
>>> features such as call forward all (cfwdall). I have a pretty good idea
>>> how to handle cfwdall using avp_ops however I'm stuck on the
>>> authentication.
>>>
>>> If a subscriber has local calling permissions (acl=local) and cfwdall
>>> their phone to a long distance number I need to respond with an
>>> informative response.
>>>
>>> In the INVITE processing in my config I have statements such as:
>>>
>>>       if (is_user_in("credentials", "ld")) {
>>>         setflag(11);
>>>       };
>>>
>>> These checks fail with the following errors:
>>>
>>> Apr 21 18:31:53 ser[498]:  [SER]: AVP: Checking From gateway caller
>>> Apr 21 18:31:53 ser[498]: check_username(): No authorized 
>>> credentials found (error in scripts)
>>> Apr 21 18:31:53 ser[498]: check_username(): Call 
>>> {www,proxy}_authorize before calling
>>>        check_* function !
>>> Apr 21 18:31:53 ser[498]: [SER]: Flag for UMVM redirect successful.
>>> Apr 21 18:31:53 ser[498]:  [SER]: AVP: Checking credentials
>>> Apr 21 18:31:53 ser[498]: is_user_in(): No authorized credentials 
>>> found (error in scripts)
>>>   
>>
>>
>>  Checking the username without authentication does not make much sense
>>  because the user could fake the contents of the header field. That's
>>  why check_* functions require authorized credentials to be present.
>>
>>  
>>
>>>  I thought adding proxy_authorize("", "subscriber")), check_to and 
>>> check_from calls prior
>>> to the is_user_in check would address these errors but that hasn't 
>>> worked either.
>>>
>>>   If I want to set a flag if the caller is an authorized subscriber, 
>>> the callee is an
>>> authorized subscriber and then use "is_user_in" to determine if the 
>>> called party has
>>> a particular credential what am I missing?
>>>   
>>
>>
>>  I am not sure I understand "the callee is an authorized subscriber".
>>  Digest authentication can only be performed for the caller, not the
>>  callee, because there is no way of challenging the callee.
>>
>>  
>>
>  Perhaps I am missing the obvious. That is why I posted this message.  
> When I wrote I was
> thinking:  Suppose someone calling in from the PSTN via a gateway 
> calls a subscriber that has
> setup call forwarding all to a PSTN number.
>
>  I need to know that this subscriber can indeed place calls to the 
> PSTN (either local, long distance
> or international) before rewriting the called address and allowing the 
> call to proceed. I was assuming
> is_user_in was appropriate for this type of checking but that fails.

you can use avpops module for this. Keep an AVP per user that is used to 
check if that user can call to PSTN. Load the AVP and check it before 
allowing the call to proceed. Something like:

modparam("avpops","avp_aliases","allow_pstn=i:500")
...
route {
...
    if(!avp_db_load("$ruri", "$allow_pstn"))
    {
          log("allow pstn AVP does not exist -- deny the call\n");
          sl_send_reply("404", "Not found");
          break;
    };
    if(!avp_check("$allow_pstn", "eq/i:1"))
    {
          log("allow pstn AVP is not set to TRUE -- deny the call\n");
          sl_send_reply("404", "Not found");
          break;
    };
    # delete AVP from memory -- no longer needed   
    avp_delete("$allow_pstn/g");

    # forward the call to PSTN
...
}

In your usr_preferences table you should have records like:

(uuid,username,domain,attribute,value,type) = ("", "username", "domain", 
"500", "1", 3)

for users that are allowed to call to PSTN and:

(uuid,username,domain,attribute,value,type) = ("", "username", "domain", 
"500", "0", 3)

or no AVP for the others.


Daniel

>
>
>
>>    Jan.
>>  
>>
>
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>




More information about the sr-users mailing list