[OpenSIPS-Users] AVP-based uac_auth in b2bua
Ovidiu Sas
osas at voipembedded.com
Tue Nov 19 19:06:40 CET 2013
This feature never worked.
It was in the TODO list, but it never reached the top :)
-ovidiu
On Tue, Nov 19, 2013 at 12:39 PM, Jeff Pyle <jpyle at fidelityvoice.com> wrote:
> Ovidiu,
>
> That makes sense. If you're right, this feature has never worked? Ticket
> 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
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
--
VoIP Embedded, Inc.
http://www.voipembedded.com
More information about the Users
mailing list