rlm_realm module, Realm attr value
G'day, FreeRADIUS rlm_realm module feeds the Realm attribute with a configured value that matched the realm as entered by the user. There is one exception. If the matched configured value is a regex, the realm as entered by the user is used to feed the Realm attribute value. There is one more case that could get this exception like treatment. If the configured realm value is "DEFAULT", the realm as entered by the user could be used to feed the Realm attribute value. Attached diff file describes the code change. Alternatively, unlang can be employed to get the details into the Realm attribute. If placed within the authorize section after the realm module instance call (the suffix instance and delimiter = '@' is assumed to be in use in this case): if (Realm == "DEFAULT" && User-Name =~ /@(.*)$/) { update request { Realm := "%{1}" } } Kind regards, Martin
On 01/24/2011 02:32 PM, Martin Stanislav wrote:
There is one more case that could get this exception like treatment. If the configured realm value is "DEFAULT", the realm as entered by the user could be used to feed the Realm attribute value. Attached diff file describes the code change.
I don't think this is a good change. For example: authorize { suffix if (Realm == DEFAULT) { # not a local realm; do some stuff attr_filter.eduroam } } ...if you change the value of the "Realm" variable, it's never possible to compare against it. We rely on this in a number of places. Since as you point out, you can already accomplish this with unlang or regexp realms, I don't think it's necessary to change the behaviour of the existing module.
On Mon, Jan 24, 2011 at 03:15:46PM +0000, Phil Mayers wrote:
If the configured realm value is "DEFAULT", the realm as entered by the user could be used to feed the Realm attribute value.
I don't think this is a good change.
For example:
authorize { suffix if (Realm == DEFAULT) { # not a local realm; do some stuff attr_filter.eduroam } }
...if you change the value of the "Realm" variable, it's never possible to compare against it. We rely on this in a number of places.
Thanks for your comments. Beeing able to differentiate a path the request is about to take is a real need. I've had an impression %{control:Proxy-To-Realm} can be referenced to get this particular information. Please, correct me in case I need to pick up on the intended attribute content and its use.
Since as you point out, you can already accomplish this with unlang or regexp realms, I don't think it's necessary to change the behaviour of the existing module.
I admit, the ability to do comparisons against the matched proxy realm value is a feature I'd like to keep. Martin
Hello,
Thanks for your comments. Beeing able to differentiate a path the request is about to take is a real need. I've had an impression %{control:Proxy-To-Realm} can be referenced to get this particular information. Please, correct me in case I need to pick up on the intended attribute content and its use.
Seems like the term "Realm" is used in an overloaded manner: on the one hand, it's the user-supplied character string, on the other hand it's a named instance of the realm module. Looks like up until 2.1.8, the AVP Realm was always created with Realm-the-character-string as it came from the request, but with 2.1.9, this changed to Realm-the-instance-name. Problem is, both of these can be valuable somehow, and need to be addressable. In a rlm_linelog, I care about logging the actual input; at other places, I may want to check which path the packet will take. In short, I think there should be two attributes: one to contain the instance name, one with the string. Using unlang is of course possible, but clumsy - it worked without before. Greetings, Stefan Winter -- 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
Stefan Winter wrote:
Seems like the term "Realm" is used in an overloaded manner: on the one hand, it's the user-supplied character string, on the other hand it's a named instance of the realm module.
Not quite... a user-supplied character string, and a named realm in the proxy.conf file. The named realms are used by the "realms" module to find a matching name.
Looks like up until 2.1.8, the AVP Realm was always created with Realm-the-character-string as it came from the request, but with 2.1.9, this changed to Realm-the-instance-name.
Hmm... I think it's the other way around. In 2.1.9, a regex realm results in "Realm = match", instead of "Realm = regex".
Problem is, both of these can be valuable somehow, and need to be addressable. In a rlm_linelog, I care about logging the actual input; at other places, I may want to check which path the packet will take.
In short, I think there should be two attributes: one to contain the instance name, one with the string. Using unlang is of course possible, but clumsy - it worked without before.
There's utility creating two attributes, I think. Alan DeKok.
On Tue, Jan 25, 2011 at 01:52:21PM +0100, Alan DeKok wrote:
The named realms are used by the "realms" module to find a matching name.
Looks like up until 2.1.8, the AVP Realm was always created with Realm-the-character-string as it came from the request, but with 2.1.9, this changed to Realm-the-instance-name.
Hmm... I think it's the other way around. In 2.1.9, a regex realm results in "Realm = match", instead of "Realm = regex".
Correct.
Problem is, both of these can be valuable somehow, and need to be addressable. In a rlm_linelog, I care about logging the actual input; at other places, I may want to check which path the packet will take.
In short, I think there should be two attributes: one to contain the instance name, one with the string. Using unlang is of course possible, but clumsy - it worked without before.
There's utility creating two attributes, I think.
CPU cycles are burned within the rlm_realm to extract both, the realm as entered by the user and the matched proxy.conf realm entry. The Proxy-To-Realm attribute holds the latter value (realm_authorize & realm_preacct function calls). The Realm attribute is set to the same value except holding a regex. It's set to the former value in such a case. In other words, "DEFAULT" proxy.conf entry is the only case, when the Realm attribute doesn't exactly match (string, case insensitive) the realm as entered by the user. Martin
On 01/25/2011 08:36 AM, Martin Stanislav wrote:
Thanks for your comments. Beeing able to differentiate a path the request is about to take is a real need. I've had an impression %{control:Proxy-To-Realm} can be referenced to get this particular information. Please, correct me in case I need to pick up on the intended attribute content and its use.
That's a good point. It's up to others (Alan) really if he wants to change the behaviour. I suspect it would be best to wait for 2.2 for a behaviour change, if so.
participants (4)
-
Alan DeKok -
Martin Stanislav -
Phil Mayers -
Stefan Winter