[OpenSIPS-Users] learning the realm from authentication challenges

Jeff Pyle jeff at ugnd.org
Fri Sep 25 14:40:18 EST 2020 

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 <Ben.Newlin at genesys.com> 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 <users-bounces at lists.opensips.org>
> *Date: *Friday, September 25, 2020 at 10:15 AM
> *To: *OpenSIPS users mailling list <users at lists.opensips.org>
> *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 <Ben.Newlin at genesys.com> 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 <users-bounces at lists.opensips.org>
> *Date: *Thursday, September 24, 2020 at 11:14 PM
> *To: *OpenSIPS users mailling list <users at lists.opensips.org>
> *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 <Ben.Newlin at genesys.com> 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 <users-bounces at lists.opensips.org>
> *Date: *Thursday, September 24, 2020 at 9:53 PM
> *To: *OpenSIPS users mailling list <users at lists.opensips.org>
> *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 <users-bounces at lists.opensips.org>
> *Date: *Thursday, September 24, 2020 at 9:31 PM
> *To: *OpenSIPS users mailling list <users at lists.opensips.org>
> *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
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200925/6692e3ab/attachment.html>

More information about the Users mailing list