(RADIATOR) Configuring AuthBy RADIUS from database?

Hugh Irvine hugh at open.com.au
Fri Sep 9 18:53:10 CDT 2005


Hello Claudio -

What I would do is use a hook to parse the results of the SQL query  
and either accept or call the AuthBy RADIUS clause.

Something like this:

<AuthBy SQL>
         Identifier CheckDatabase
         .....
</AuthBy>

<AuthBy SQLRADIUS>
         Identifier ProxyToRemote
         .....
</AuthBy>

<Handler>
         <AuthBy INTERNAL>
                 DefaultResult ACCEPT
                 RequestHook file:"%D/ProcessRequest
         </AuthBy>
</Handler>

The hook code in ProcessRequest would call CheckDatabase and parse  
the result then either respond directly or call the ProxyToRemote.

You will need to check the code in Radius/AuthSQLRADIUS.pm and Radius/ 
AuthRADIUS.pm for details.

There are a number of example hooks in "goodies/hooks.txt" in the  
Radiator 3.13 distribution.

regards

Hugh


On 10 Sep 2005, at 07:55, Claudio Lapidus wrote:

> Hello all,
>
> We have a situation where we need to use different authentication
> methods based on responses received in run-time from an external
> database. Specifically, there are situations where it may be needed to
> proxy the request to one of different remote radius servers, while in
> other cases the request can be resolved locally. In the former cases
> the database will answer with the necessary data to prepare the proxy
> operation, while in the latter the DB's answer will contain the
> definitive attributes for include in the Access-Accept.
>
> This is an example of the values the DB returns when a proxy operation
> is needed:
>
> sqlplus> SELECT radius.packradius.fretatt FROM dual;
>
> radius.packradius.fretatt
> ---------------------------------------------------------------------- 
> -----------
> X-Modo=Proxy,X-Host0=10.0.0.95,X-AuthPort0=1812,X-AcctPort0=1813,X- 
> Secret0=server1,X-Host1=10.0.0.95,X-AuthPort1=2812,X- 
> AcctPort1=2813,X-Secret1=server2
>
>
> And this is when a local accept is generated:
> sqlplus> SELECT radius.packradius.fretatt FROM dual;
>
> radius.packradius.fretatt
> ---------------------------------------------------------------------- 
> -----------
> X-Mode=Accept,Service-Type=Framed,Framed-Protocol=PPP,Framed-IP- 
> Address=1.1.1.1
>
>
> (the DB will tell whether it's appropiate or not to proxy based on
> other criteria, not shown in the example)
>
>
> So far, the following config reflects our idea:
>
> <AuthBy SQL>
>        Identifier      WithSQL
>        DBSource        dbi:Oracle:host=streamer;sid=ORCL
>        DBUsername      x
>        DBAuth          x
>
>        AuthSelect  SELECT radius.packradius.fretatt FROM dual
>        AuthColumnDef 0, GENERIC,reply
> </AuthBy>
>
> <AuthBy RADIUS>
>  Identifier RemoteRadius
>  Host x.x.x.x
>  etc...
> </AuthBy>
>
> <AuthBy INTERNAL>
>        Identifier IgnoreIfProxy
>        RequestHook file:"/etc/radiator/IgnoreIfNotProxy.cfg"
>        DefaultResult ACCEPT
> </AuthBy>
> <Handler>
>        Identifier Default
>        <AuthBy GROUP>
>                AuthByPolicy ContinueWhileIgnore
>                <AuthBy GROUP>
>                        AuthByPolicy ContinueAlways
>                        AuthBy WithSQL
>                        AuthBy IgnoreIfProxy
>                </AuthBy>
>                AuthBy RemoteRadius
>        </AuthBy>
> </Handler>
>
> this is the hook mentioned above:
> ---------------------------------------------------------------------- 
> -
> #/etc/radiator/IgnoreIfNotProxy.cfg
> sub {
>        my ($p,$rp,$ch) = @_;
>
>        my $mode=$rp->get_attr('X-Mode');
>
>        #&main::log($main::LOG_DEBUG, "MODE=$mode");
>        return ($main::IGNORE, "Ignored for continue with proxy!") if
> $mode=~/^Proxy$/i;
>        return ($main::ACCEPT);
> }
> ---------------------------------------------------------------------- 
> -
>
> So, our intention is to have RemoteRadius somehow receive its
> parameters (Host, etc.) in runtime, instead of having it statically
> defined. We are aware that we could use SQLRADIUS for this, but we are
> trying to avoid a second DB access. Can anybody devise a way to
> achieve this?
>
> thanks in advance
> cl.
>
> --
> 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 read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive (www.open.com.au/archives/ 
radiator)?
Have you had a quick look on Google (www.google.com)?
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.


More information about the radiator mailing list