[sr-dev] [ openser-Bugs-2740437 ] PUBLISH authentication is wrong

SourceForge.net noreply at sourceforge.net
Mon Jun 15 16:14:03 CEST 2009


Bugs item #2740437, was opened at 2009-04-07 13:28
Message generated for change (Comment added) made by klaus_darilion
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2740437&group_id=139143

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: ver devel
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Klaus Darilion (klaus_darilion)
Assigned to: Nobody/Anonymous (nobody)
Summary: PUBLISH authentication is wrong

Initial Comment:
Hi!

For PUBLISH requests, Authentication user should be checked against RURI. Thus, realm should be derived from RURI too.

Can someone please review the patch - I am not sure if the usage of &(_m->parsed_uri) is correct in this situation.

thanks


----------------------------------------------------------------------

>Comment By: Klaus Darilion (klaus_darilion)
Date: 2009-06-15 16:14

Message:
I also think it is better to just remove the automated realm-calculation
and instead force to script writer to specify the realm in the config.

----------------------------------------------------------------------

Comment By: Iñaki Baz Castillo (ibc_sf)
Date: 2009-05-19 15:40

Message:
The original question was about the default "realm" to set if
ww_authorize() hasn't it set. The reporter suggested to take the default
realm from the RURI domain but IMHO (as debated in the ML) this is wrong
(take for example an external presence user agent which publish status for
other AoR's with different domains. In this case, the PUA should
authenticate with his own username (pua at external_domain.org) and not with
the domain in the RURI (alice at atlanta.org).

The best option, IMHO, would be never setting the default realm from any
part of the request. Instead, it must be set manually by the script
configurator by choosing $fd, $rd, $td...

AFAIR all of this was explained in the devel maillist.

----------------------------------------------------------------------

Comment By: Daniel-Constantin Mierla (miconda)
Date: 2009-05-19 09:31

Message:
IMO, the from has to be auth'ed as well. Other opinions? Can we close
this?

Anyhow, auth module allows to use username from any field with
pv_proxy|www_authorize(). proxy|www_challenge() takes any PV as realm
parameter. So the behaviour can be achieved with sqlops (to load passwed
from db) and auth for the rest.

----------------------------------------------------------------------

Comment By: Iñaki Baz Castillo (ibc_sf)
Date: 2009-04-16 15:50

Message:
I copy part of my mail in devel maillist about this report:

I don't agree on the patch behaviour. For PUBLISH the credentials username
should be matched against the From username. For example, a presence user
agent (pua at domain) could publish state for bob at domain.org, but we still
need pua to authenticate against us. In my opinion, the logical behaviour
would be:

is_method("PUBLISH") {

 if !  check_from() {
   sl_send_reply("403", "You are not who you say");
   exit();
 }

 if au != fu {
     if fu == "sip:pua at domain" {
       xlog("L_INFO", "Thirdy party PUBLISH allowed for PUA \n");
     }
     else {
       sl_send_reply("403", "Thirdy Party PUBLISH not allowed for you");
       exit();
    }
 }

}


So I consider the proposed patch as wrong since it avoids authenticated
thirdy party publish.


----------------------------------------------------------------------

Comment By: Iñaki Baz Castillo (ibc_sf)
Date: 2009-04-14 17:23

Message:
I have no checked the patch yet, but I confirm that for PUBLISH, the RURI
should be checked instead of the From or To.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2740437&group_id=139143



More information about the sr-dev mailing list