[RADIATOR] Authby REST: ACCEPT/REJECT

[C R]

Thank you again, Heikki. The solution you proposed worked out great.
For the future readers, I ended doing this:

<AuthBy REST>
Debug
Identifier ssid-iotd
URL {{ injected }}
TLS_Protocols TLSv1.2
TLS_CAFile /etc/ssl/certs/DigiCert_Assured_ID_Root_CA.pem
HTTP_AuthenticationScheme Basic
HTTP_Username radius
HTTP_Password URL {{ injected }}
RequestMethod POST
RestAuthRequestDef mac, %U, literal, formatted
RestAuthRequestDef ip, %N, literal, formatted
RestAuthRequestDef endpoints, /v2/mac/iotd:/v2/mac/ipsk-u, literal
RestAuthReplyDef reply,GENERIC,reply
NoReplyReject
ServerChecksPassword
</AuthBy>

The response looks like this:
OK:

{
"type": "auth",
"time": "2022-01-07T16:25:28.896480569+01:00",
"authorized": true,
"auth_type_attr": "Auth-Type=Accept",
"endpoint": "/v2/mac/iotd",
"psk": "foopassword",
"psk_fallback": false,
"vlan": "x-dyn-ipskinfra",
"reply": "Tunnel-Type=VLAN,Tunnel-Medium-Type=802,Tunnel-Private-Group-ID=x-dyn-ipskinfra,cisco-avpair=psk-mode=ascii,cisco-avpair=psk=foopassword"
}

NOK:
{
"type": "auth",
"time": "2022-01-07T16:32:55.54294293+01:00",
"authorized": false,
"auth_type_attr": "Auth-Type=Reject:rejected by x"
}

Regards,

CR

Le lun. 20 déc. 2021 à 16:21, C R <publist.cr at gmail.com> a écrit :
>
> 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