[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