(RADIATOR) passing information between Radiators and authby question

[Hugh Irvine]

Hello Viraj -

I think I would write a PreClientHook that would figure out what VISP a 
request was for and add a pseudo-attribute to the request indicating which 
one. Something like VISP-Identifier = xxxxx would do nicely. Then you can 
simply have one Handler for each VISP:

# define Handlers

<Handler VISP-Identifier = xxxxx>
	.....
</Hanlder>

<Handler VISP-Identifier = yyyyy>
	.....
</Handler>

.....

There are some example hooks in the file "goodies/hooks.txt".

regards

Hugh


On Mon, 3 Jun 2002 23:08, Viraj Alankar wrote:
> On Mon, Jun 03, 2002 at 05:32:20PM +1000, Hugh Irvine wrote:
> > Hello Viraj -
> >
> > Could you please give me a bit more detail on your requirements?
> >
> > I am sure we can come up with a better solution than modifying code.
>
> Hugh,
>
> Basically what we are trying to do is handle many different VISPs. Using
> the standard flat Handler configuration would require up to thousands of
> Handlers for every possible authentication combination in our situation
> (NAS IP, NAS IP+DNIS, regex NAS IP, realm, etc...). So the first thing I am
> trying to do is move towards the below type of configuration so that the
> number of handlers can be reduced.  I want to first check for NAS IP, then
> branch further down from there. I believe this will reduce processing quite
> a bit.
>
> So normally we would have:
>
> <Handler NAS-IP-Address = 1.2.3.4, Calling-Station-Id = 111>
>         AuthBy Some_SQL
>         if Auth, Append a Class to tag this as a certain VISP for
> accounting </Handler>
>
> Where the above AuthBy gets accounting and auth. That is, our VISPs are
> defined as some combination of NAS IP, DNIS, Realm, username prefix, or
> some regex involving these.
>
> We make this instead:
>
> <Handler NAS-IP-Address = 1.2.3.4>
>         <AuthBy FILE>
>                 Filename nas-1.2.3.4
>         </AuthBy>
> </Handler>
>
> And in nas-1.2.3.4 we would have:
>
> DEFAULT Calling-Station-Id = 111, Auth-Type = Some_SQL
>         Class = "visp_info"
>
> This config would seem to work for authentication, but for accounting I am
> unsure. I think I just need to add 'AuthenticateAccounting' to the AuthBy
> FILE.
>
> Viraj.
>
> > On Sun, 2 Jun 2002 10:31, Viraj Alankar wrote:
> > > > > Another question I have is using Auth-By in a users file. For
> > > > > example:
> > > > >
> > > > > <Handler NAS-IP-Address = 1.2.3.4>
> > > > >         <AuthBy FILE>
> > > > >                 Filename nas-1.2.3.4
> > > > >         </AuthBy
> > > > > </Handler>
> > > > >
> > > > > nas-1.2.3.4:
> > > > >
> > > > > DEFAULT Calling-Station-Id = 111, Auth-Type = DoA
> > > > >
> > > > > DEFAULT Calling-Station-Id = 222, Auth-Type = DoB
> > >
> > > Hello Hugh,
> > >
> > > I just realized something about my proposed config above, in that DoA
> > > and DoB will not get accounting. Basically 'DoA' and 'DoB' correspond
> > > to 2 different virtual ISPs and I need the accounting handled for each
> > > one differently, but in other words they need to GET the accounting.
> > >
> > > My guess is I need to write a new auth module that inherits AuthFILE.
> > > Looking at this I think I just need to add some code to call
> > > AuthGeneric::checkAttributes on an accounting request instead of just
> > > accepting it. Do you think that modification will work ok?
> > >
> > > Just FYI, the reason I am looking at the above type of configuration is
> > > I would like to reduce the number of handlers. We simply would have too
> > > many if we did this with all Handlers. The goal with the above config
> > > is to emulate a 'sub-handler' or cascading setup, where first the NAS
> > > IP is matched, then Calling-Station-Id only if NAS IP had matched. This
> > > will reduce the amount of processing for each packet. If you think
> > > there is some better way please let me know.
> > >
> > > Thanks,
> > >
> > > Viraj.
> >
> > --
> > Radiator: the most portable, flexible and configurable RADIUS server
> > anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
> > -
> > Nets: internetwork inventory and management - graphical, extensible,
> > flexible with hardware, software, platform and database independence.

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
===
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.