[RADIATOR] Authby REST: ACCEPT/REJECT

[Heikki Vatiainen]

On 18.12.2021 16.05, C R wrote:

> After reading the Radiator documentation and code, it's not completely
> clear to me how Radiator determines if a request should is accepted or
> rejected by a "AuthBy REST".

There are a couple of ways to do this. Because the AuthBy does not 
require a certain response, but can be configured to match what the 
server responds, a couple of examples are in order. I'll also see that 
the reference manual and configuration sample get updated.

> This is the relevant Radiator configuration:
> RestAuthRequestDef mac, %{Calling-Station-Id}
> RestAuthRequestDef ip, %{NAS-IP-Address}
> RestAuthRequestDef endpoints, /v2/mac/iotdr:/v2/mac/iodtd-u, literal
> RestAuthReplyDef reply,Reply,reply

Related to example below: If you have a number of attributes=value pairs 
in the "reply" key, do this:

RestAuthReplyDef reply,GENERIC,reply

> This is the (stripped down) response of my REST service (used for MAB
> and iPSK for now):
> {
>    "authorized": true,
>    "reply": "Reply-Message=accepted by
> rest,Tunnel-Type=VLAN,Tunnel-Medium-Type=802,Tunnel-Private-Group-ID=vlan1,cisco-avpair=psk-mode=ascii,cisco-avpair=psk=foo123"
> }
> or
> {
>    "authorized": false,
>    "reply": "Reply-Message=rejected by rest"
> }
> 
> I thought of using the "authorized" key in the response to make the
> decision, but I only see a way to add this to the reply, not as the
> result. Does Radiator expect an specific HTTP Statuscode (401, 404?)
> to identify a REJECT? I can adapt the REST service to what's needed,
> so pointers in that direction are also appreciated.

In this case there's no attributes in the request that can be configured 
to values returned with the JSON reply. Please find below some options:

1) You can use 401 or other non-OK status codes. These also require 
'NoReplyReject' flag parameter to ensure that a timed out or non-OK 
reply triggers a reject.


2) Within Handler (or Client) add to request the desired authorization 
result. X-Authorized is a private pseudo attribute which does not need 
to exist in the dictionary:

<Handler ...>
   # Use 1 or 0 with JSON booleans
   AddToReply X-Authorized = 1

   <AuthBy REST>
       # Current configuration

       RestAuthReplyDef authorized,X-Authorized,check

       # Rest of current configuration

Within REST response failure is:

     "authorized": false

And success is:

     "authorized": true
or
     <key not present at all>



3) Use Auth-Type reply attribute.

Within AuthBy REST configuration:

     RestAuthReplyDef authorized,GENERIC,check

Within REST response failure is:

     "authorized": "Auth-Type=Reject:Bad MAC"

The text following 'Reject:' becomes the reject reason in the 
authentication log.

And success is:

     "authorized": "Auth-Type=Accept"
or
     <key not present at all>



With 2) and 3) you need to be careful to include the "authorized" key 
when you want to reject the user. In other words, if the user should be 
accepted, you can leave out "authorized" completely. The follows the 
logic with SQL and other AuthBys where check and reply items are only 
evaluated if the server returns them.

The logic for this is that this allows, for example, returning a static 
IP or some other reply or check attribute the just some of the users. 
The configuration on Radiator side can list them but it's the server's 
decision if they are used or not.



Finally, there's also MapResponseHook that allows doing custom 
modifications to the OK responses. However, it's likely that this is not 
needed here, but it's available in case the responses need processing 
soon after they are received but before they are processed further.

https://files.radiatorsoftware.com/radiator/ref/MapResponseHook_common_httpclient.html 


-- 
Heikki Vatiainen
OSC, makers of Radiator
Visit radiatorsoftware.com for Radiator AAA server software