(RADIATOR) Feature Request, Patch attached: AuthBy SQL and PostAuthSelectHook

[Hugh Irvine]

Hi Charly -

Many thanks for your contribution (again...).

best regards

Hugh



On 25 Nov 2004, at 02:08, Karl Gaissmaier wrote:

> Hi Mike or Hugh and all Radiator lovers,
>
> we have a big Oracle user database as backend, storing
> account and service data for all our users. If we want to
> block one service for an user (like WLAN access if his Laptop
> is infected with viruses and trojans) we set a flag in the
> database to disable just the WLAN access for this user, still
> providing the e-mail and other services.
>
> AuthSQL isn't smart enough to deal with this until I change
> the table definitions. Even the parameter AuthColumnDef can't
> solve this. Until now I had a really poor workaround with the
> (maybe Oracle specific) SQL function decode():
>
> # trick: return check-item Auth-Type = Accept|Reject
> AuthColumnDef   0, Auth-Type, check
>
> # select service disable flag
> AuthSelect  SELECT decode(sign(disflag), 0, 'Accept', 'Reject')\
>                FROM ....
>
>
> this could be really better done with a PostAuthSelectHook:
>
> AuthColumnDef        0, Auth-Type, check
>
> PostAuthSelectHook   sub { my ($self, $name, $p, $user, $row) = @_; \
>                            my $flag = $row->[0];                    \
>                            $row->[0] = $flag ? 'Reject' : 'Accept'; \
>                           }
>
> with the following hook parameter documentation
> (similar to AuthBy LDAP and PostSerchHook):
>
> 6.29.23 PostAuthSelectHook
>
> This optional parameter allows you to define a Perl function that will 
> be run during the authentication process. The hook will be called 
> after the AuthSelect results have been received, and after Radiator 
> has processed the attributes it is interested in.
>
> The first argument passed to the hook is a handle to the current 
> AuthBy SQL object. The second argument is the name of the user being 
> authenticated. The third argument is a pointer to the current request. 
> The fourth argument is a pointer to the User object being constructed 
> to hold the check and reply items for the user being authenticated.
> The fifth argument ($_[4]) is a reference to the @row resulting from 
> AuthSelect.
>
> (Example missing, goodies missing)
>
> With this PostAuthSelectHook you can use ANY database schema.
> This would be much more powerful than AuthColumnDef since in this
> hook you can rewrite all @row values, add check- reply items
> directly to the user object and much more.
>
> I would appreciate it if you could incorporate this feature
> in the 3.11 patches and the next Radiator release.
>
> Thanks in advance
>     Charly
>
> P.S. really small patch attached
>
> -- 
> Karl Gaissmaier       KIZ/Infrastructure, University of Ulm, Germany
> Email:karl.gaissmaier at kiz.uni-ulm.de           Service Group Network
> Tel.: ++49 731 50-22499
> --- old/AuthSQL.pm	2004-11-24 15:52:46.945153000 +0100
> +++ new/AuthSQL.pm	2004-11-24 15:52:22.327465000 +0100
> @@ -16,6 +16,7 @@
>  %Radius::AuthSQL::ConfigKeywords =
>      ('AccountingTable'       => 'string',
>       'AuthSelect'            => 'string',
> +     'PostAuthSelectHook'    => 'hook',
>       'EncryptedPassword'     => 'flag',
>       'AcctSQLStatement'      => 'stringarray',
>       'AuthSQLStatement'      => 'stringarray',
> @@ -225,6 +226,9 @@
>      {
>  	$user = new Radius::User $name;
>
> +	# Perhaps run a hook to do other things with the SELECT data
> +	$self->runHook('PostAuthSelectHook', $p, $self, $name, $p, $user, 
> \@row);
> +
>  	# If the config has defined how to handle the columns
>  	# in the AuthSelect statement with AuthColumnDef, use
>  	# that to extract check and reply items from
>

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.