[OpenSIPS-Users] AVP-based uac_auth in b2bua
Jeff Pyle
jpyle at fidelityvoice.com
Tue Nov 19 18:39:28 CET 2013
Ovidiu,
That makes sense. If you're right, this feature has never worked?
Ticket<https://github.com/OpenSIPS/opensips/issues/134>submitted
(#134). Thanks for your help.
- Jeff
On Tue, Nov 19, 2013 at 12:18 PM, Ovidiu Sas <osas at voipembedded.com> wrote:
> I think this is something that will require some coding ...
> There are two tm transactions:
> - a UAS transaction for the received INVITE;
> - a UAC transaction for the newly generated INVITE.
>
> The AVPs are stored by the first tm transaction and invisible for the
> second tm transaction.
> The authentication is happening on the second tm transaction and since
> the AVPs are invisible, the authentication cannot be performed.
> The parameter based authentication credentials are visible on both
> transactions and therefor the authentication process is successful.
>
> Again, this is what I think ... I haven't had a chance to check the
> code in detail.
> Best thing to do is open a bug report.
>
> Regards,
> Ovidiu Sas
>
> On Mon, Nov 18, 2013 at 9:37 PM, Jeff Pyle <jpyle at fidelityvoice.com>
> wrote:
> > Yes:
> >
> > # ----- tm params -----
> > modparam("tm", "fr_timer", 2)
> > modparam("tm", "fr_inv_timer", 118)
> > modparam("tm", "disable_6xx_block", 1)
> > modparam("tm", "restart_fr_on_each_reply", 0)
> > modparam("tm", "onreply_avp_mode", 1)
> >
> >
> > - Jeff
> >
> >
> > On Mon, Nov 18, 2013 at 7:36 PM, Ovidiu Sas <osas at voipembedded.com>
> wrote:
> >>
> >> Did you set the onreply_avp_mode for tm:
> >> http://www.opensips.org/html/docs/modules/devel/tm.html#id293972
> >>
> >>
> >> On Monday, November 18, 2013, Jeff Pyle wrote:
> >>>
> >>> It's 1.10 pulled from git a few hours ago. Debian 7 64-bit.
> >>>
> >>> The AVPs are set prior to calling the b2b scenario:
> >>>
> >>> modparam("uac_auth","auth_realm_avp", "$avp(auth_realm)")
> >>> modparam("uac_auth","auth_username_avp","$avp(auth_user)")
> >>> modparam("uac_auth","auth_password_avp","$avp(auth_pass)")
> >>> #modparam("uac_auth","credential","UserName:AuthRealm123:SuperS33cret")
> >>>
> >>> route {
> >>> ...
> >>> $avp(auth_user) := "UserName";
> >>> $avp(auth_pass) := "SuperS33cret";
> >>> $avp(auth_realm) := "AuthRealm123";
> >>>
> >>> b2b_init_request("top hiding/t105");
> >>> ...
> >>> }
> >>>
> >>>
> >>> debugs:
> >>>
> >>> Nov 18 18:07:55 [26004] DBG:b2b_entities:b2b_tm_cback: Received reply
> >>> [407] for dialog [0x7ff941c13268], method [INVITE]
> >>> Nov 18 18:07:55 [26004] DBG:tm:t_unref_cell: UNREF_UNSAFE:
> >>> [0x7ff941c18448] after is 1
> >>> Nov 18 18:07:55 [26004] DBG:b2b_entities:b2b_tm_cback:
> >>> dlg=[0x7ff941c13268], uac_tran=NULL
> >>> Nov 18 18:07:55 [26004] DBG:core:parse_authenticate_body:
> >>> <realm>="AuthRealm123" state=2
> >>> Nov 18 18:07:55 [26004] DBG:core:parse_authenticate_body:
> >>> <nonce>="528a9de900013e5f13fe985df4a9848356a1f937207ecfe4" state=3
> >>> Nov 18 18:07:55 [26004] DBG:core:parse_authenticate_body: <qop>="auth"
> >>> state=1
> >>> Nov 18 18:07:55 [26004] DBG:b2b_logic:b2bl_parse_key: hash_index =
> [472]
> >>> - local_index= [0]
> >>>
> >>>
> >>>
> >>> The following (successful) debugs occur if I uncomment the credential
> >>> modparam visible above:
> >>>
> >>> Nov 18 18:15:45 [26118] DBG:b2b_entities:b2b_tm_cback:
> >>> dlg=[0x7f8a06744c30], uac_tran=NULL
> >>> Nov 18 18:15:45 [26118] DBG:core:parse_authenticate_body:
> >>> <realm>="66.94.76.24" state=2
> >>> Nov 18 18:15:45 [26118] DBG:core:parse_authenticate_body:
> >>> <nonce>="528a9fbf00014297ef8f2335679f0310537c85fe2b007186" state=3
> >>> Nov 18 18:15:45 [26118] DBG:core:parse_authenticate_body: <qop>="auth"
> >>> state=1
> >>> Nov 18 18:15:45 [26118] DBG:uac_auth:build_authorization_hdr: auth_hdr
> is
> >>> <Proxy-Authorization: Digest username="UserName", realm="AuthRealm123",
> >>> nonce="528a9fbf00014297ef8f2335679f0310537c85fe2b007186",
> >>> uri="sip:2165551212 at domain", qop=auth, nc=00000001,
> cnonce="3105687311",
> >>> response="ef047011046690b6eea99c7848de499a", algorithm=MD5
> >>> >
> >>> Nov 18 18:15:45 [26118] DBG:b2b_entities:b2b_tm_cback:
> >>> [Proxy-Authorization: Digest ...]
> >>> Nov 18 18:15:45 [26118] DBG:b2b_entities:b2b_tm_cback: uri [...]
> >>>
> >>>
> >>>
> >>> I tried to follow the source to isolate the failing mechanism. I
> arrived
> >>> at modules/uac_auth/auth.c. In get_avp_credential() at line 199:
> >>>
> >>> avp = search_first_avp( realm_avp_type, realm_avp_name, &val,
> 0);
> >>> if ( avp==NULL || (avp->flags&AVP_VAL_STR)==0 || val.s.len<=0 )
> >>> return 0;
> >>>
> >>> In my case I've discovered avp==NULL so the if-statement returns 0.
> >>> avp==NULL because in the search_first_avp() at line 346 of usr_avp.c:
> >>>
> >>> if (*crt_avps==0)
> >>> return 0;
> >>>
> >>> And it's game over. I can't discern what causes this. I'm already way
> >>> in over my pay grade. :)
> >>>
> >>>
> >>> - Jeff
> >>>
> >>>
> >>> On Mon, Nov 18, 2013 at 6:02 PM, Ovidiu Sas <osas at voipembedded.com>
> >>> wrote:
> >>>
> >>> Can you post the debug logs and let us know which version of opensips
> >>> are you running?
> >>> Also, make sure that you set the credentials in AVPs before invoking
> >>> the b2b call.
> >>>
> >>> Thanks,
> >>> Ovidiu
> >>>
> >>> On Mon, Nov 18, 2013 at 5:11 PM, Jeff Pyle <jpyle at fidelityvoice.com>
> >>> wrote:
> >>> > This functionality has become key for my configuration. I've done
> some
> >>> > digging today. Here's what I know.
> >>> >
> >>> > b2b_entities' auth call gets to around line 347 of usr_avp.c and
> fails:
> >>> >
> >>> > if (*crt_avps==0)
> >>> > return 0;
> >>> >
> >>> > Programming is not my strength. Any thoughts what might cause this
> >>> > condition, or how it might be related b2b_entities' ability to
> process
> >>> > an
> >>> > auth request?
> >>> >
> >>> >
> >>> > - Jeff
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > On Wed, Nov 13, 2013 at 6:03 PM, Jeff Pyle <jpyle at fidelityvoice.com>
> >>> > wrote:
> >>> >>
> >>> >> Hi Ovidiu,
> >>> >>
> >>> >> It does not. At least not for me. Here are some snippets of my
> >>> >> config
> >>> >> file:
> >>> >>
> >>> >> modparam("uac_auth","auth_realm_avp", "$avp(auth_realm)")
> >>> >> modparam("uac_auth","auth_username_avp","$avp(auth_user)")
> >>> >> modparam("uac_auth","auth_password_avp","$avp(auth_pass)")
> >>> >>
> >>> >>
> >>> >>
> #modparam("uac_auth","credential","valid-username:appropriate-realm:valid-password")
> >>> >>
> >>> >> route {
> >>> >>
> >>> >> ... sanity checks, etc ...
> >>> >>
> >>> >> $avp(auth_realm) := "appropriate-realm";
> >>> >> $avp(auth_user) := "valid-username";
> >>> >> $avp(auth_pass) := "valid-password";
> >>> >>
> >>> >> if !(b2b_init_request("top hiding/t105")) {
> >>> >> xlog("L_ERR", "** b2b_init failed - - S=$si:$sp
> T=$tU
> >>> >> F=$fU C=$ci\n");
> >>> >> send_reply("500", "Internal Server Error");
> >>> >> }
> >>> >> exit;
> >>> >> }
> >>> >>
> >>> >>
> >>> >> Configured like this, the 407 gets passed back to the client. If I
> >>> >> uncomment the 'credential' modparam, the B2B will send an INVITE
> with
> >>> >> the
> >>> >> correct auth.
> >>> >>
> >>> >> The same uac_auth config with the same AVPs work correctly if I use
> >>> >> uac_auth() on a failure_route in a pure proxy config. That's why
> I'm
> >>> >> confused about it not working with the B2B. I looked through the
> >>> >> source and
> >>> >> as best I can tell the same functions are called the same way for
> >>> >> each.
> >>> >>
> >>> >> Ok, let me be specific on that last point. The client to this B2B
> >>> >> instance is another Opensips instance with proxy-only commands, most
> >>> >> notably
> >>> >> rtpproxy. That's where I have uac_auth() working today. With that
> I
> >>> >> call
> >>> >> the scenario here as "top hiding/at105" (note the "a") to
> >>> >> intentionally pass
> >>> >> the 407 back to the proxy config. It works. Ideally, I'd prefer
> the
> >>> >> B2B
> >>> >> scenario here field the 407.
> >>> >>
> >>> >>
> >>> >> - Jeff
> >>> >>
> >>> >>
> >>> >> On Wed, Nov 13, 2013 at 4:34 PM, Ovidiu Sas <osas at voipembedded.com>
> >>> >> wrote:
> >>> >>>
> >>> >>> If you set the AVPs before creating the b2b call, it should work on
> >>> >>> 1.10.
> >>> >>>
> >>> >>> Regards,
> >>> >>> Ovidiu Sas
> >>> >>>
> >>> >>> On Tue, Nov 12, 2013 at 11:16 PM, Jeff Pyle <
> jpyle at fidelityvoice.com>
> >>> >>> wrote:
> >>> >>> > I was about to let this one go when I found "B2B module gets
> >>> >>> > visibility
> >>> >>> > to
> >>> >>> > credentials defined via AVPs" on the About Version 1.10 page. In
> >>> >>> > my
> >>> >>> > case it
> >>> >>> > works only if I define the 'credential' modparam for uac_auth.
> >>> >>> >
> >>
> >>
> >>
> >> --
> >> VoIP Embedded, Inc.
> >> http://www.voipembedded.com
> >>
> >> _______________________________________________
> >> 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
> >
>
>
>
> --
> VoIP Embedded, Inc.
> http://www.voipembedded.com
>
> _______________________________________________
> 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/20131119/023b6159/attachment-0001.htm>
More information about the Users
mailing list