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@domain) could publish state for bob@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@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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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@external_domain.org) and not with the domain in the RURI (alice@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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have no checked the patch yet, but I confirm that for PUBLISH, the RURI should be checked instead of the From or To.
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@domain) could publish state for bob@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@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.
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.
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@external_domain.org) and not with the domain in the RURI (alice@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.
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.