[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