(RADIATOR) PreProcessingHook to bypass further processing

[Hugh Irvine]

Hello Kwang -

Yes I think what you show below should work.

Of course you will need to test it thoroughly to verify correct 
operation.

BTW - you can specify multiple check items and use regular expressions 
in Handlers:

<Handler SomeThing = /some_regexp/, AnotherThing = /anotherregexp/, 
.....>
	....
</Handler>

regards

Hugh


On 11 Feb 2004, at 11:13, Kwang Moon wrote:

> Hi Hugh,
>
> Yes I had thought about using an AuthBy INTERNAL clause, but with a
> RequestHook but wasn't sure if what I wanted to do would work.  What 
> do you
> think:
>
> <AuthBy INTERNAL>
>    Identifier IntAuth
>    RequestHook file: "reqhook.pl"
>    DefaultResult ACCEPT
> <\AuthBy>
>
> <AddressAllocator SQL>
>    Identifier AddrAlloc
>    ...
> <\AddressAllocator>
>
> <AuthBy DYNADDRESS>
>    Identifier DynAddrAuth
>    AddressAllocator AddrAlloc
>    PoolHint %N-%{NAS-Identifier}
>    ...
> <\AuthBy>
>
> <Handler Request-Type=Access-Request>
>    AuthByPolicy ContinueUntilReject
>    AuthBy IntAuth
>    AuthBy DynAddrAuth
>    ...
> <\Handler>
>
> reqhook.pl would look something like this:
> Sub {
>    do something
>    $somevar = ({$_[0]}->get_attr('some attribute');
>    if $($somevar eq 'aaa')  {
>       $({$_[0]}->add_attr('PoolHint', $somevar);
>       return $main::ACCEPT;
>    } else if $($somevar eq 'bbb')  {
>       $({$_[0]}->add_attr('PoolHint', $somevar);
>       return $main::ACCEPT;
>    } else {
>       return $main::REJECT;
>    }
> }
>
> So based on the above, if I returned an ACCEPT in the hook, would the 
> next
> AuthBy clause be invoked (in accordance to the AuthByPolicy), and 
> similary
> if I returned a REJECT, then would an Access-Reject be sent to the 
> client
> without the next AuthBy clause being invoked?
>
> As for the default handler you mentioned - we can't really use this as 
> we
> use the handler check item value as a variable to the PoolHint, so we 
> need
> to be certain that it's correct (ie not misspelt, missing etc.)  If the
> above config works, then it will acheive the same result, albeit in a 
> not so
> friendly way.  That's why a feature like that of IdenticalClients, but 
> for a
> handler would be really useful.
>
>
> Cheers,
> Kwang
>
>
>
>
> ----- Original Message -----
> From: "Hugh Irvine" <hugh at open.com.au>
> To: "Kwang Moon" <kwang.moon at O2.com>
> Cc: <radiator at open.com.au>
> Sent: Tuesday, February 10, 2004 10:02 PM
> Subject: Re: (RADIATOR) PreProcessingHook to bypass further processing
>
>
>>
>> Hello Kwang -
>>
>> The usual way to do what you describe is to use an AuthBy INTERNAL
>> clause followed by a PostAuthHook.
>>
>> For your question about Handlers, it is more usual to specify a final
>> <Handler> to catch "everything else".
>>
>> # deal with something specific
>>
>> <Handler ......>
>> .....
>> </Handler>
>>
>> # deal with everything else
>>
>> <Handler>
>> .....
>> </Handler>
>>
>>
>> regards
>>
>> Hugh
>>
>>
>> On 11 Feb 2004, at 01:57, Kwang Moon wrote:
>>
>>> Hi,
>>>
>>> Does anyone know if it's possible to carry out some checks in a
>>> PreProcessingHook, and based on the results to immediately halt the
>>> handling
>>> process and send back a $main::REJECT to the client?
>>>
>>> The reason I want to do this is because I have heaps of handlers (all
>>> pretty
>>> much doing the same thing), the only difference being the handler 
>>> check
>>> item.  So, what I want to do is create one handler to deal with say
>>> Access-Request packets and then verify the check item within the say 
>>> a
>>> PreProcessingHook (ie if it doesn't match then somehow send a reject
>>> immediately without further processing, and if it passes then 
>>> continue
>>> with
>>> hook and return back to the handler).
>>>
>>> There was a posting earlier last year:
>>> http://www.open.com.au/archives/radiator/2003-05/msg00147.html
>>> asking a very similar question, however, there didn't appear to be a
>>> resolution.
>>>
>>> If this is not possible, then (a question to Mike or Hugh) what's the
>>> likelihood of getting a feature added to the handler clause similar 
>>> to
>>> the
>>> IdenticalClients.  It could look something like:
>>> IdenticalHandlers <attribute=value, attribute=value, ...>
>>>
>>>
>>> Cheers,
>>> Kwang
>>>
>>>
>>>
>>> ===
>>> Archive at http://www.open.com.au/archives/radiator/
>>> Announcements on radiator-announce at open.com.au
>>> To unsubscribe, email 'majordomo at open.com.au' with
>>> 'unsubscribe radiator' in the body of the message.
>>>
>>>
>>
>> NB: have you included a copy of your configuration file (no secrets),
>> together with a trace 4 debug showing what is happening?
>>
>> -- 
>> Radiator: the most portable, flexible and configurable RADIUS server
>> anywhere. Available on *NIX, *BSD, Windows, MacOS X.
>> -
>> Nets: internetwork inventory and management - graphical, extensible,
>> flexible with hardware, software, platform and database independence.
>> -
>> CATool: Private Certificate Authority for Unix and Unix-like systems.
>>
>
> ===
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with
> 'unsubscribe radiator' in the body of the message.
>
>

NB: have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.

===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.