[OpenSIPS-Users] learning the realm from authentication challenges

johan johan at democon.be
Fri Sep 25 15:27:51 EST 2020


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 <Ben.Newlin at genesys.com 
> <mailto: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
>     <mailto: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
>     <mailto: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
>     <mailto: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
>         <mailto: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
>         <mailto: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 <mailto: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
>             <mailto: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 <mailto: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
>             <mailto: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 <mailto: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 <mailto:Users at lists.opensips.org>
>             http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>         _______________________________________________
>         Users mailing list
>         Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>         http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>     _______________________________________________
>     Users mailing list
>     Users at lists.opensips.org <mailto: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/733c0e2b/attachment-0001.html>


More information about the Users mailing list