[OpenSIPS-Users] AVP-based uac_auth in b2bua
Ovidiu Sas
osas at voipembedded.com
Tue Nov 19 18:18:03 CET 2013
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 visible, 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
More information about the Users
mailing list