Handling user based on an attribute in a dynamic manner
Hi, I’m working on a solution where I need to auth differently, and return different attributes based on a user’s access type. I can see the interface that a user has arrived on, and from that look up the access type. We have maybe 100 different interfaces which can change a bit, divided in to 3 or 4 different access types. Once I know the access type, I can choose which of the other attributes I use to authenticate the user. We run 3.0.16 (or will by the time this is deployed). I’m trying to figure out a good way to map those 100 interfaces to access types, without a change meaning a restart. We run LDAP right now, we don’t have SQL servers running on our front end servers, and I’d rather avoid it. Right now, I’m considering SQLite, but I’m not certain how it would handle: 1) A 3rd party process opening the db file to write periodically - I see posts about only one writer, and that’s fine I only want one writer, but I want to write from a different application.. is that OK? 2) Changes to the file, would they require a restart - I presume the DB file is not cached in memory in FreeRADIUS somehow, but that’s just a guess. Our auth load is quite manageable, so, if a request blocked for a second or two while the write was happening that would be OK - but errors/false negatives would be bad. Can anyone help with these before I go spending a bunch of time testing? Any other solutions I should consider? A server restart is always an option, but, I’d rather avoid it if possible. -- Nathan Ward
On 10 Feb 2018, at 10:26, Nathan Ward <lists+freeradius@daork.net> wrote:
Any other solutions I should consider? A server restart is always an option, but, I’d rather avoid it if possible.
You could run a redis instance locally on each system. For your dataset, it'd require a tiny amount of memory. I do this for VLAN assignment from our corporate MDM - I have a python script that queries the MDM's backend, builds the list, then connects to each instance In turn and updates it. Regards, Adam Bishop gpg: E75B 1F92 6407 DFDF 9F1C BF10 C993 2504 6609 D460 jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.
On Feb 10, 2018, at 5:26 AM, Nathan Ward <lists+freeradius@daork.net> wrote:
I’m working on a solution where I need to auth differently, and return different attributes based on a user’s access type. I can see the interface that a user has arrived on, and from that look up the access type. We have maybe 100 different interfaces which can change a bit, divided in to 3 or 4 different access types. Once I know the access type, I can choose which of the other attributes I use to authenticate the user. We run 3.0.16 (or will by the time this is deployed).
I’m trying to figure out a good way to map those 100 interfaces to access types, without a change meaning a restart.
We run LDAP right now, we don’t have SQL servers running on our front end servers, and I’d rather avoid it.
Right now, I’m considering SQLite, but I’m not certain how it would handle: 1) A 3rd party process opening the db file to write periodically - I see posts about only one writer, and that’s fine I only want one writer, but I want to write from a different application.. is that OK?
Yes.
2) Changes to the file, would they require a restart - I presume the DB file is not cached in memory in FreeRADIUS somehow, but that’s just a guess.
They won't require a restart. If the updates are fast (i.e. sub millisecond), it won't really affect the server much.
Our auth load is quite manageable, so, if a request blocked for a second or two while the write was happening that would be OK - but errors/false negatives would be bad.
Updates should be less than 1ms in the normal case.
Can anyone help with these before I go spending a bunch of time testing?
Any other solutions I should consider? A server restart is always an option, but, I’d rather avoid it if possible.
rlm_passwd can do this, too. See "man rlm_passwd" Alan DeKok.
participants (3)
-
Adam Bishop -
Alan DeKok -
Nathan Ward