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 <h...@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@lists.open.com.au > https://lists.open.com.au/mailman/listinfo/radiator _______________________________________________ radiator mailing list radiator@lists.open.com.au https://lists.open.com.au/mailman/listinfo/radiator