Please document dynamic in proxy server section in proxy.conf
Hi. The dynamic key was introduced to enable realms_realm_add after config parsing. However, it doesn't seem to be documented in the default raddb.
The dynamic key was introduced to enable realms_realm_add after config parsing. However, it doesn't seem to be documented in the default raddb.
Arran, Alan, is there any other use case for using 'dynamic'? Retrieval of realms from a database? Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet 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 Collections and Janet Ltd. is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under Company No. number 2881024, VAT No. GB 197 0632 86. The registered office is: Lumen House, Library Avenue, Harwell, Didcot, Oxfordshire, OX11 0SG. T 01235 822200.
On 18 Mar 2015, at 18:20, Stefan Paetow <Stefan.Paetow@jisc.ac.uk> wrote:
The dynamic key was introduced to enable realms_realm_add after config parsing. However, it doesn't seem to be documented in the default raddb.
Arran, Alan, is there any other use case for using 'dynamic'? Retrieval of realms from a database?
I really dislike how the current dynamic realms stuff is currently implemented. I'll likely redo it for v3.1.x so it uses a virtual server to gather the realm information. There's demand for realms loaded from LDAP/SQL. So yes, in future it could mean load the realm from a database or directory. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
So yes, in future it could mean load the realm from a database or directory.
Ok, I'll tweak the explanation :-) Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet 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 Collections and Janet Ltd. is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under Company No. number 2881024, VAT No. GB 197 0632 86. The registered office is: Lumen House, Library Avenue, Harwell, Didcot, Oxfordshire, OX11 0SG. T 01235 822200.
If you're looking at designing dynamic realms here are the parts we use that might not be preserved in all designs: * Being able to dynamically specify tls information * Per Alan's recommendation, being able to have home servers that are not part of the standard rbtrees, so we can avoid a security exposure. If two realms claim to be served by a server with IP address 192.0.2.23, we don't want one of these realms to be able to overwrite the key for the other. Either both keys will work for the same IP address, or someone is being dishonest, but it's important not to combine home servers in this instance just because they have the same IP and hostname * Being able to have the over-the-wire realm name different than the internal representation. (The suffix of the user-name attribute ends up not being the same as the realm name returned) * Being able to evaluate periodically with access to connection stats for the home servers whether a realm is still good or whether we want to dynamically contact it again
Hi,
If two realms claim to be served by a server with IP address 192.0.2.23, we don't want one of these realms to be able to overwrite the key for the other. Either both keys will work for the same IP address, or someone is being dishonest, but it's important not to combine home servers in this instance just because they have the same IP and hostname
That is, hostname and port? The same IP can run multiple servers on different ports with different keys. There's no dishonesty in any of that. Stefan
* Being able to have the over-the-wire realm name different than the internal representation. (The suffix of the user-name attribute ends up not being the same as the realm name returned)
* Being able to evaluate periodically with access to connection stats for the home servers whether a realm is still good or whether we want to dynamically contact it again - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
-- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
On Mar 19, 2015, at 2:57 AM, Stefan Winter <stefan.winter@restena.lu> wrote:
If two realms claim to be served by a server with IP address 192.0.2.23, we don't want one of these realms to be able to overwrite the key for the other. Either both keys will work for the same IP address, or someone is being dishonest, but it's important not to combine home servers in this instance just because they have the same IP and hostname
That is, hostname and port? The same IP can run multiple servers on different ports with different keys. There's no dishonesty in any of that.
No. The problem is different. Let’s say we have a proxy which uses *one* list for home servers. In that case, I can take *everyones* roaming down with a simple configuration. 1) I sign up for a roaming consortium, as example.org 2) When proxies ask for my RADIUS server information, I give them *my* certificate, and the RADIUS IP / port for example.com 3) a user logs into the proxy with example.com, and gets the example.com RADIUS server IP/port 4) the certificate presented for that IP/port is for example.org, so the example.com roaming will fail As a result, the home server TLS information *must* be kept separate for each realm. Alan DeKok.
participants (5)
-
Alan DeKok -
Arran Cudbard-Bell -
Sam Hartman -
Stefan Paetow -
Stefan Winter