(RADIATOR) passing information between Radiators and authby question

[Hugh Irvine]

Hello Viraj -

I would not recommend doing what you describe below.

The reason I have shown a pseudo-attribute (VISP-Identifier) is to make the 
hook code and the configuration file as clear as possible so everyone can 
easily understand what is going on.

regards

Hugh


On Wed, 5 Jun 2002 01:47, Viraj Alankar wrote:
> 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.

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