(RADIATOR) passing information between Radiators and authby question

[Viraj Alankar]

On Tue, Jun 04, 2002 at 06:47:25AM +1000, Hugh Irvine wrote:
> 
> 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".

Hm, yes this seems like a much better idea, thanks.

One question, if my PreClientHook can also figure out what AuthBy should be
used, is there a way I could pass this parameter to the Handlers?

For example, if I analyze a packet in PreClientHook and determine it should be
authenticated with the AuthBy XXX, if I were to place this information in the
packet, could I do something like the following:

<Handler AuthBy-String = /.+/>
        AuthBy %{AuthBy-String}
</Handler>

i.e., get the AuthBy name from the packet?

Viraj.

> 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.