[RADIATOR] RequestHook in AuthBy RADIUS

Hugh Irvine hugh at open.com.au
Fri Apr 24 18:41:30 CDT 2015


Hi Jose -

Right - understood.

In this case I would probably use separate Radiator processes as intermediates between your main server and the targets that require special AVpair processing.

You would forward the original request unchanged and then deal with whatever changes are required on the intermediate Radiator instances.

I tend to use this architecture quite often as it makes each individual piece much simpler and cleaner.

Something like this:

…..

<Handler Client-Identifier=PGW, Acct-Status-Type=Start>

       Identifier      PGW_START
       AccountingHandled

       <AuthBy  GROUP>
               AuthByPolicy ContinueAlways

               <AuthBy RADIUS>
                       # Forward to intermediate instance
                       Host                    localhost
                       AcctPort              11812
                       Secret                  secret2
                       IgnoreAccountingResponse
               </AuthBy>

               <AuthBy RADIUS>
                       # Forward to intermediate instance
                       Host                    localhost
                       AcctPort              11813
                       Secret                  secret3
                       IgnoreAccountingResponse
               </AuthBy>

               <AuthBy RADIUS>
                       # Forward to intermediate instance
                       Host                    localhost
                       AcctPort              11814
                       Secret                  secret4
                       IgnoreAccountingResponse
               </AuthBy>

               <AuthBy RADIUS>
                       Host                    192.168.1.5
                       Secret                  secret5
                       IgnoreAccountingResponse
               </AuthBy>

               <AuthBy RADIUS>
                       Host                    192.168.1.6
                       Secret                  secret6
                       IgnoreAccountingResponse
               </AuthBy>

     </AuthBy>

       MaxSessions     0
</Handler>


BTW - I agree with you that a RequestHook would be a useful addition in any case.

regards

Hugh


> On 25 Apr 2015, at 00:35, Jose Borges Ferreira <underspell at gmail.com> wrote:
> 
> Hi,
> 
> 
> I have somthing similar to this:
> 
> <Handler Client-Identifier=PGW, Acct-Status-Type=Start>
>        Identifier      PGW_START
>        AccountingHandled
> 
>        <AuthBy  GROUP>
>                AuthByPolicy ContinueUntilReject
>                <AuthBy RADIUS>
>                        Host                    192.168.1.2
>                        Secret                  secret2
>                        StripFromRequest        AVP1__2,AVP2__2
>                        AllowInRequest          3GPP-IMSI,
> Acct-Session-Id, NAS-Port-Type\
>                                                Acct-Status-Type,
> Called-Station-Id, Calling-Station-Id, Event-Timestamp,
> Framed-IP-Address, User-Name
>                </AuthBy>
>                <AuthBy RADIUS>
>                        Host                    192.168.1.3
>                        Secret                  secret3
> 
>                        RequestHook     sub {\
>                                my $p   = ${$_[0]};\
>                                my $fp  = ${$_[1]};\
>                                my $imsi = $p->get_attr('3GPP-IMSI');\
>                                if ($imsi =~ /^1234/) { \
> 
> $fp->change_attr('3GPP-RAT-Type,', 'UMTS');\
> 
>                                }\
>                        }
> 
>                        AllowInRequest          3GPP-IMSI,
> 3GPP-PDP-Type, 3GPP-RAT-Type, 3GPP-User-Location-Info,
> Acct-Session-Id,NAS-Port-Type \
>                                                Acct-Status-Type,
> Called-Station-Id, Calling-Station-Id, Event-Timestamp,
> Framed-IP-Address, User-Name
> 
>                </AuthBy>
>                <AuthBy RADIUS>
>                        Host                    192.168.1.4
>                        Secret                  secret3
>                        AllowInRequest          3GPP-RAT-Type,
> 3GPP-User-Location-Info, Acct-Session-Id, NAS-Port-Type\
>                                                Acct-Status-Type,
> Called-Station-Id, Calling-Station-Id, Event-Timestamp,
> Framed-IP-Address, User-Name
>                </AuthBy>
> 
>                <AuthBy RADIUS>
>                        Host                    192.168.1.5
>                        Secret                  secret4
>                </AuthBy>
> 
>                <AuthBy RADIUS>
>                        Host                    192.168.1.6
>                        Secret                  secret5
>                </AuthBy>
>      </AuthBy>
> 
> 
>        MaxSessions     0
> </Handler>
> 
> 
> ( not exactly this but similar enough)
> 
> 
> I want o achieve the following:
> 
> 1.Broadcast accounting to all servers.
> 2.Have a different set of AVPs for each destination server.
> 3.To one server ( and only to that one) want to have a more complex
> logic and be able to add,remove or change AVPs
> 
> In other setups I found that changing avps on one clause it will send
> AVP changes to the following servers, which was not intended
> 
> I achieved the intended behaviour by enclosing a AuthBy RADIUS in a
> GROUP  between a couple of INTERNALs. The first one to change the AVP
> and a final one to restore from original packet.
> 
> I found a RequestHook very useful and more clean approach. It is the
> counterpart of the Reply/NoReplyHook .
> I thought it could be useful for other and, eventually, included in
> next versions.
> 
> Thanks anyway,
> 
> Best regards,
> 
> José Borges Ferreira
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Wed, Apr 22, 2015 at 7:21 AM, Hugh Irvine <hugh at open.com.au> wrote:
>> 
>> Hello Jose -
>> 
>> One way to do this is with multiple Handler clauses and an AuthBy HANDLER clause in the first one.
>> 
>> See the example in “goodies/authhandler.cfg”.
>> 
>> See also section 5.76 AuthBy HANDLER in the manual (“doc/ref.pdf”).
>> 
>> You can have a different PreAuthHook in each target Handler clause, and the overall configuration will be much simpler.
>> 
>> I would also have separate configuration files for authentication and accounting (each listening only on the corresponding ports).
>> 
>> hope that helps
>> 
>> regards
>> 
>> Hugh
>> 
>> 
>> 
>>> On 22 Apr 2015, at 01:26, Jose Borges Ferreira <underspell at gmail.com> wrote:
>>> 
>>> Hi all,
>>> 
>>> I have a setup that forwards some accounting to several servers. I
>>> need to mangle some attributes before a forward to the remote
>>> server.One requirement is to have different mangling per host.
>>> I couldn't found a way to change hook some code at AuthBy RADIUS, so I
>>> implemented the attached patch.
>>> 
>>> So , my question is :
>>> 
>>> Is there a way to achieve what I want ?
>>> 
>>> Does the patch makes sense ?
>>> 
>>> Thanks in advanced,
>>> 
>>> José Borges Ferreira
>>> <RequestHook.patch>_______________________________________________
>>> radiator mailing list
>>> radiator at open.com.au
>>> http://www.open.com.au/mailman/listinfo/radiator
>> 
>> 
>> --
>> 
>> Hugh Irvine
>> hugh at open.com.au
>> 
>> Radiator: the most portable, flexible and configurable RADIUS server
>> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
>> Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
>> TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
>> DIAMETER, SIM, etc.
>> Full source on Unix, Linux, Windows, MacOSX, Solaris, VMS, NetWare etc.
>> 


--

Hugh Irvine
hugh at open.com.au

Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, 
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER, SIM, etc. 
Full source on Unix, Linux, Windows, MacOSX, Solaris, VMS, NetWare etc.



More information about the radiator mailing list