Jeff, be warned that the datafill for registrar is not obvious.
On 25/09/2020 16:40, Jeff Pyle wrote:
I am not route-advancing in a typical way, so my application of
credentials is a bit different perhaps.
The environment I'm in has a variety of customer-facing platforms,
over a dozen at last count. Some are for trunking, some hosted, some
hybrid. The platform I'm writing on OpenSIPS is a testing one that
will allow us to send and receive test calls to and from all of them.
So, rather than having a bunch of registrations on every test phone
for every person who might want to test, this allows each person to
have one appearance to this platform and select which upstream
platform they want to send a call to via dialed prefixes.
I use the uac_registrant module, and its registrant table, to handle
the platforms that require registrations and it works excellently. At
call time, I'm working on the scripting right now that will query the
registrant table for the appropriate credentials based on where we've
sent the call and apply them in the failure_route upon receiving a 401
or 407.
Think of it this way: when you configure a gateway in FreeSWITCH or a
SIP peer in Asterisk's chan_sip, do you need to define the realm ahead
of time? No, you don't care; it's just a mechanism under the hood
that's necessary to complete the transaction. That's where I'm at in
OpenSIPS. With Johan's parsing it looks like I'm about there, too.
Friggin' regex gets me every time.
- Jeff
On Fri, Sep 25, 2020 at 10:25 AM Ben Newlin <[email protected]
<mailto:[email protected]>> wrote:
I think you do need to have credentials associated with the
different routes you have and load those properly. From your
description, however, I don’t understand why it is dependent on
identifying the realm in the response. If multiple downstream
servers are all using the same realm (but have different
credentials?) then how are you differentiating based on the realm
value?
The idea with uac_auth is that when you send, for example, to
server broadworks1 you would load all the possible valid
credentials for broadworks1, including the realm it will challenge
with. When you then call uac_auth() from failure route, it will
look through all the loaded credentials for one with a matching
realm to the broadworks1 challenge and use that. If the call fails
for any reason to broadworks1 and then you decide to route to
server asterisk1, you would load all the possible credentials for
that server into the auth AVPs the same way and failure route
handling is the same.
You could very well have a use case for verifying the realm in
failure_route; I’m not saying you don’t. I don’t see it from what
you’ve described, but I may be missing something. I think the
reason there is no variable for pulling the challenge realm value
directly is because normally with this mechanism it shouldn’t be
needed.
I would appreciate if someone could confirm that uac_auth() will
match the realm as I’m asserting. I’m 95% sure this is how it
worked in my testing, but that was a while ago and as I said the
realm matching doesn’t appear to be documented. I’d hate to be
steering you down a wrong path.
Ben Newlin
*From: *Users <[email protected]
<mailto:[email protected]>>
*Date: *Friday, September 25, 2020 at 10:15 AM
*To: *OpenSIPS users mailling list <[email protected]
<mailto:[email protected]>>
*Subject: *Re: [OpenSIPS-Users] learning the realm from
authentication challenges
Johan,
I will definitely try that. Thank you!
Ben,
The problem is I have multiple destinations with the same
realm. In my case, several different Broadworks app servers. I
haven't checked them exhaustively but I think they all reply with
realm="BroadWorks" in their authentication headers. I've got some
Asterisk boxes in here, and I think they're all the domain of the
SIP request URI in the case of an INVITE. I think I'll have to
choose ahead of time which credentials go with which route, no?
Unless I'm still not wrapping my head around how this is supposed
to work.
- Jeff
On Fri, Sep 25, 2020 at 9:22 AM Ben Newlin <[email protected]
<mailto:[email protected]>> wrote:
Jeff,
My point was that the uac_auth() is supposed to handle the
realm matching for you. If you simply load all of the auth
data based on the call target as you already plan to do,
uac_auth() should look through that data for you to find
credentials with a matching realm. You don’t need to do that
part yourself in the script.
Ben Newlin
*From: *Users <[email protected]
<mailto:[email protected]>>
*Date: *Thursday, September 24, 2020 at 11:14 PM
*To: *OpenSIPS users mailling list <[email protected]
<mailto:[email protected]>>
*Subject: *Re: [OpenSIPS-Users] learning the realm from
authentication challenges
Good catch on Proxy-Authorization vs Proxy-Authenticate. I
think I've been looking at this too long. I checked the
module and that's exactly what it is.
My hope was to load the uac_auth user/pass AVPs ahead of time
from a DB based on where I knew I was sending the call, load
the realm one in the failure route based on what comes back in
the header, and then fire the uac_auth() function. It looks
like I may have to manually extract the realm from whichever
header comes in. Not ideal, but probably workable.
- Jeff
On Thu, Sep 24, 2020 at 9:58 PM Ben Newlin
<[email protected] <mailto:[email protected]>> wrote:
This does not appear to be documented, but I believe
uac_auth() looks through the AVPs configured in the
UAC_AUTH module and uses the first one whose realm matches
the challenge realm. So in order to authenticate any
challenge, you must load all of the possible credentials
into those AVPs.
Ben Newlin
*From: *Users <[email protected]
<mailto:[email protected]>>
*Date: *Thursday, September 24, 2020 at 9:53 PM
*To: *OpenSIPS users mailling list
<[email protected] <mailto:[email protected]>>
*Subject: *Re: [OpenSIPS-Users] learning the realm from
authentication challenges
According to the docs, $ar provides the realm from the
“Authorization” or “Proxy-Authorization” headers. Not from
the ”Proxy-Authenticate” header, which is what you have.
https://www.opensips.org/Documentation/Script-CoreVar-3-1#toc6
Ben Newlin
*From: *Users <[email protected]
<mailto:[email protected]>>
*Date: *Thursday, September 24, 2020 at 9:31 PM
*To: *OpenSIPS users mailling list
<[email protected] <mailto:[email protected]>>
*Subject: *[OpenSIPS-Users] learning the realm from
authentication challenges
I'm trying to recover the realm of an auth challenge to
OpenSIPS so I can respond to it with the uac_auth()
function, and that requires knowing the realm. The docs
say that $ar
<https://www.opensips.org/Documentation/Script-CoreVar-3-1#toc6>
should provide that, perhaps written like $(<reply>ar) to
get it in the right context. I'm having some trouble
getting the data.
failure_route[relay_failure] {
...
if (t_check_status("407")) {
xlog("L_NOTICE", "[1] Proxy-Authenticate:
$(<reply>hdr(Proxy-Authenticate))\n");
xlog("L_NOTICE", "[2] Auth Realm:
$(<reply>ar)\n");
xlog("L_NOTICE", "[3] Auth Realm: $ar\n");
}
...
}
The logs show:
/usr/sbin/opensips[33044]: [1] Proxy-Authenticate: Digest
realm="asterisk",
nonce="5f6d42140000936ad820dbcd452e6bcd145777e458dd46dd",
qop="auth"
/usr/sbin/opensips[33044]: [2] Auth Realm reply: <null>
/usr/sbin/opensips[33044]: [3] Auth Realm: <null>
Is it possible to get the realm? Is it possible to build
a response with uac_auth() for an arbitrary authentication
challenge?
This is on 3.1.0~20200923~88f89e941.
- Jeff
_______________________________________________
Users mailing list
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
