(RADIATOR) PreProcessingHook to bypass further processing

[Kwang Moon]

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.