[RADIATOR] Custom Reply-Message for each AuthSQL inside REALM

[Heikki Vatiainen]

On 07/04/2012 04:32 PM, Alby wrote:

Hello Alberto,

> I am using Radiator in a Telecommunication group. I have only one REALM,
> with 3 AuthSQL statements inside (the policy used is
> ContinueWhileIgnore). The first one checks that the user is allowed to
> occupy another port in the system. If the check goes OK, then the next
> AuthSQL statement is executed, otherwise the user is rejected due to the
> unavailability of physical resources. The second one checks that the
> call originating form Calling-Station-ID to Called-Station-ID
> (attributes present in the user's request packet) is not prohibited,
> like a sort of blacklist. If also this check goes OK then the last
> AuthSQL statement performs the real user authentication.

Try pairing an AuthBY INTERNAL with each AuthBy SQL. If I understood
correctly, you now have this:

<Realm ...>
  AuthByPolicy ContinueWhileIgnore
  AuthBy SQL1
  AuthBy SQL2
  AuthBy SQL3
</Realm>

If e.g., SQL1 is now an AuthBy SQL with Identifier SQL1, you could
change it to this:

<AuthBy GROUP>
  Identifier SQL1
  # Or any other policy that suits the outcome from AuthBy SQL
  AuthByPolicy ContinueWhileIgnore
  <AuthBy SQL>
      ....
  </AuthBy>
  <AuthBy INTERNAL>
      AuthHook sub {...}
  </AuthBy>
</AuthBy>

See goodies/digipassStatic.cfg for an example where INTERNALs are used
to run hooks between/after each "real" AuthBy.

> My question is: each AuthSQL modules can add (independently to others
> Auth modules) custom messages to the log (maybe with the function
> &main::log) and to the reply packet? In other words, I would like that
> if a user is rejected because of lack of resources, a string like "User
> rejected because of lack of resources" is written on the logs and maybe
> in the user's response with a Reply-Message attribute. In a similar way,
> if the user is rejected due to blacklist rules, a string like "User
> rejected due to blacklist" is added to the log and to the user's
> response packet. My first try was to do this using PostAuthHooks like
> done in the past, but Hooks are for REALMs, not for single AuthBy
> statements if I am not mistaken.

That's true. PostAuthHook, for example, runs once when all AuthBys, as
directed by AuthByPolicy, have run. With the above INTERNAL example, you
can have more control when to run the hooks.

> I have noticed that AuthSQL have the
> PostAuthSelectHook, but this is executed before Radiator performs the
> authentication operations. This force me to understand if the user is
> blocked twice, one time in the Hook and another time by Radiator and
> this does not make very sense I think. Maybe there is a better way to
> reach my goal, but I really can't see how to do that.

Please get back to us and tell if the above works.

Thanks,
Heikki

-- 
Heikki Vatiainen <hvn at open.com.au>

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.