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
_______________________________________________
radiator mailing list
[email protected]
https://lists.open.com.au/mailman/listinfo/radiator
