(RADIATOR) PreProcessingHook to bypass further processing

[Kwang Moon]

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.