(RADIATOR) PreProcessingHook to bypass further processing

[Hugh Irvine]

Hello Kwang -

You are correct - multiple checks are logical "and".

You can do logical "or" in a single check with a regexp:

<Handler SomeCheck = /one|two|three/, ....>
	....
</Handler>

regards

Hugh


On 12 Feb 2004, at 04:37, Kwang Moon wrote:

> Hugh,
>
> Multiple check items in the handler clause are logical 'and' right? - 
> or are
> you telling me that I can somehow do logical 'or' as well (which is 
> what I
> need)...
> I'm assuming this is 'and':
> <Handler attribute1=value, attribute2=value>
>
>
> 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: Wednesday, February 11, 2004 2:53 AM
> Subject: Re: (RADIATOR) PreProcessingHook to bypass further processing
>
>
>>
>> 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.
>
>

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.