[RADIATOR] Authby REST: ACCEPT/REJECT

[C R]

Thank you, Heikki! I will try it out. It looks very flexible. Updating
the documentation will certainly facilitate the usage of this rather
new functionality (the authby being async is a huge win).

CR

Le lun. 20 déc. 2021 à 15:59, Heikki Vatiainen <hvn at open.com.au> a écrit :
>
> 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
> radiator at lists.open.com.au
> https://lists.open.com.au/mailman/listinfo/radiator