[Serusers] clarification about authentication

Greger V. Teigre greger at teigre.com
Sat Aug 27 12:14:23 CEST 2005


A quick reply without verifying, so no guarantees on the quality of the 
answers...
> www_authorize , will this always fail, ? because it seems to and then a 
> www.challenge is sent.

If the message has included digest credentials and the nonce value has not 
expired, it will not fail, but just verify the credentials without an extra 
authentication.

> In www.challenge, is it okay to leave the realm blank, as I have done, or 
> is it better practice to have the same realm as that in www_authorise("", 
> "1");

I think leaving it blank (both www_authorize and challenge) is better if you 
have multiple domains, as the realm will be implicit.  However, I believe 
you should either set both or none.

> check_to should only be run if auth is correct above , is that correct?

That's correct.

> Why run check_to at all, ?

Because the username and authorization can be set to different values. As 
the username is registered as the location, you can for example use email 
address for authentication and a phone number for username. The user will 
then be accessible through the phone number, but not email address. However, 
the user may configure the device with ANY phone number unless you check 
that the username is allowed for this particular authentication user.  This 
check is what check_to enforces by making sure that authentication user and 
username are equal.

> and then u have proxy_auth and proxy_challenge, and is_from_local and 
> is_uri_local, surely all these dont need to be used as checks in INVITE or 
> do they.

The first two are for security, the last two are for routing:
is_from_local checks the caller's domain part agains the DB of local 
domains. If you use domain when authentication the INVITE, you don't need 
is_from_local as a security measure, but rather as a way to detect messages 
from local UACs.
is_uri_local does the same for the destination (callee) to determine whether 
it's local.

g-) 




More information about the sr-users mailing list