[EXTERNAL] rlm_rest: Adding additional parameters

Tue Mar 1 15:11:35 UTC 2022

How about using virtual servers to solve the issue. This in the clients.conf you could do.
Client device1 {
                ipaddr = <IP radius comes from on device1>
                secret = <RADIUS secret>
                virtual_server = Erricson
}

Client device2 {
                Ipaddr = < IP radius comes from on device1>
                secret = <RADIUS secret>
                virtual_server = ERX
}

Server Erricson {
                Authorize {
                                …
                }
                …
}

Server ERX {
                Authorize {
                                …
                }
                …
}

Yes, it would be some duplicate configuration but I’m assuming it won’t be one you keep for a long time. Or just pass the ‘IP’ of the RADIUS client / NAS-IP /…. to the function instead of type and have a tiny DB/File holding the IP to Type mappings for your backend code to process.

--
Alister Winfield

From: Freeradius-Users <freeradius-users-bounces+alister.winfield=sky.uk at lists.freeradius.org> on behalf of Rens Houben via Freeradius-Users <freeradius-users at lists.freeradius.org>
Date: Tuesday, 1 March 2022 at 12:45
To: FreeRadius Users mailing list <freeradius-users at lists.freeradius.org>
Cc: Rens Houben <rhouben at systemec.nl>
Subject: [EXTERNAL] rlm_rest: Adding additional parameters
Hello all,

I'm going to elaborate a bit on my current situation just in case I'm hitting an XY problem. I'll try to be succinct; please bear with me.

I've got a FreeRADIUS setup that's working well - the RADIUS server calls a REST API to handle access requests, which connects to a database that's administered via a web frontend. Smooth sailing, and has been for several years.

However, due to circumstances involving the company that supplied (and supplies the support for) our core routers going out of the router biz we've had to acquire new core routers from a different vendor... And, perhaps unsurprisingly, said vendor's hardware speaks a different dialect.

The good news, such as it is, is that with some judicious parallel naming the actual /values/ can stay the same, but the /attribute names/ will change. Worse (from my perspective), my manager would very much like it if, while both sets of core routers are connected to our network, a connection attempt could be handled by either type of router while only being a single "Connection" entry in the frontend.

Thankfully, I'm - if I say so myself - a fairly decent programmer and I've been able to rewrite the code logic so that the getAttributes() call (which creates the json dictionary that is then sent back by the REST API as the response) takes a 'vendor' parameter which pertinent parts use to determine how to respond -- IE, for a certain part, getAttributes('Ericsson') will yield '{'Qos-Metering-Profile-Name': 'test-down', 'Qos-Policing-Profile-Name': 'test-up'}' whereas getAttributes('ERX') yields '{'ERX-Ingress-Policy-Name': 'test-up', 'ERX-Egress-Policy-Name': 'test-down'}'

This part works and has been tested, but what I now need is to find a good way to /supply/ that 'Vendor' parameter to the function.

I've already restructured the FreeRADIUS config to use virtual servers so that I'll be able to use a different processing path depending on which client is asking, but I'm currently blanking on how best to add a 'Vendor=<...>' attribute to the REST request.

I'd prefer to do that in the authorize{} function but I'm not 100% sure if I can just use update{} to add an arbitrary variable to the request.

Worst case, which I'd prefer to avoid, I could just create two different copies of rlm_rest, one for the Ericssons and one for the ERXen and send them to different entry points in the REST API, but that'd require a whole lot more code duplication than I'm comfortable with.

I'd welcome any suggestions or recommendations or "You're overthinking it, just use <Z>".

--Rens Houben
-
List info/subscribe/unsubscribe? See https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeradius.org%2Flist%2Fusers.html&data=04%7C01%7Calister.winfield%40sky.uk%7Cea262e0de46947e671fd08d9fb816014%7C68b865d5cf184b2b82a4a4eddb9c5237%7C0%7C0%7C637817355465357015%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=KO7F6KAv4LtElHL2MQjZor6rawWvwFh0Enr0TuOu5hQ%3D&reserved=0
--------------------------------------------------------------------
This email is from an external source. Please do not open attachments or click links from an unknown or suspicious origin. Phishing attempts can be reported by using the report message button in Outlook or sending them as an attachment to phishing at sky.uk. Thank you
--------------------------------------------------------------------
Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky Limited and Sky International AG and are used under licence.

Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD