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

[Alby]

Hello Heikki,
the solution you proposed is working fine, thanks. I had also to adjust the
AuthByPolicy parameter that must be different in the various AuthBy Groups.
Just in case it could be useful to somebody else, I am reporting here a
skeleton of my Radiator configuration file.

<Realm REALM>
    AuthByPolicy ContinueWhileAccept

    #Check that there are ports available
    <AuthBy GROUP>
        Identifier Auth1
        AuthByPolicy ContinueWhileReject
        <AuthBy SQL>
            ...
        </AuthBy>

        #Because of the AuthByPolicy for this group, this AuthByInternal
will be executed only
        #if the previous AuthBySQL returns Rejects. Here I write error
messages
        <AuthBy INTERNAL>
            AuthHook sub { } #Print errors messages because of the lack of
resources
        </AuthBy>
    </AuthBy> #End of the Auth1 AuthBy Group

    #Now check that the user is not blacklisted
    <AuthBy GROUP>
        Identifier Auth2
        AuthByPolicy ContinueWhileReject
        #Check that there are ports available
        <AuthBy SQL>
            ...
        </AuthBy>

        <AuthBy INTERNAL>
            AuthHook sub { } #Print errors messages because the user is
blacklisted
        </AuthBy>
    </AuthBy> #End of the Auth2 AuthBy Group

    #Then authenticate the user in the usual manner
    <AuthBy SQL>
        ...
    </AuthBy>
</Realm>

Thanks again,
Alberto



2012/7/4 Heikki Vatiainen <hvn at open.com.au>

> 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.
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open.com.au/pipermail/radiator/attachments/20120706/1b6f19d7/attachment.html