[OpenSIPS-Users] AVP-based uac_auth in b2bua
Jeff Pyle
jpyle at fidelityvoice.com
Tue Nov 19 00:34:43 CET 2013
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.
> >>> >
> >>> > The AVPs do work if I use the uac_auth() function in a failure_route
> >>> > instead
> >>> > of the B2BUA top hiding.
> >>> >
> >>> > Is there a trick I'm missing?
> >>> >
> >>> >
> >>> >
> >>> > - Jeff
> >>> >
> >>> >
> >>> > On Mon, Nov 11, 2013 at 11:09 AM, Jeff Pyle <jpyle at fidelityvoice.com
> >
> >>> > wrote:
> >>> >>
> >>> >> Hello,
> >>> >>
> >>> >> I have uac_auth() working with AVPs in a proxy configuration on
> v1.10.
> >>> >> This is important because I need to choose the authentication
> username
> >>> >> and
> >>> >> password based on the usr_preferences of the source IP of the call.
> >>> >> Is it
> >>> >> possible choose the credentials at call-time (like the AVPs allow)
> in
> >>> >> a B2B
> >>> >> top-hiding scenario?
> >>> >>
> >>> >> The scenario authenticates properly if I statically specify a
> >>> >> "credentials" modparam for uac_auth. It does not work, however, if
> I
> >>> >> set
> >>> >> AVPs prior to calling b2b_init_request("top hiding"). Is there
> >>> >> another way
> >>> >> to approach this?
> >>> >>
> >>> >>
> >>> >> Regards,
> >>> >> Jeff
> >>> >>
> >>> >
> >>> >
> >>> > _______________________________________________
> >>> > 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
>
> _______________________________________________
> 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/20131118/ad17d9e8/attachment-0001.htm>
More information about the Users
mailing list