[rlm_rest] do not translate attribute values

classic Classic list List threaded Threaded
9 messages Options
| Threaded
Open this post in threaded view
|

[rlm_rest] do not translate attribute values

Michael Schneider
Hi

I have created a REST server to process incoming RADIUS requests. During development I noticed that some attributes signal the "wrong" type. I think this is due to xlat.

For example, the attributes "Tunnel-Type" and "Tunnel-Medium-Type" are both integers, but their values are serialized as strings:

"Tunnel-Type": {"type": "integer", "value": ["VLAN"]},
"Tunnel-Medium-Type": {"type": "integer", "value": ["IEEE-802"]}

This behavior makes it difficult to write a parser without knowing the numeric value of "VLAN" and "IEEE-802". Is there a configuration parameter that prevents the rlm_rest module from translating attribute values?

Thanks in advance,
Michael
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

smime.p7s (5K) Download Attachment
| Threaded
Open this post in threaded view
|

Re: [rlm_rest] do not translate attribute values

Jorge Pereira-2

> On 17 Dec 2020, at 09:25, Michael Schneider <[hidden email]> wrote:
>
> Hi
>
> I have created a REST server to process incoming RADIUS requests. During development I noticed that some attributes signal the "wrong" type. I think this is due to xlat.
>
> For example, the attributes "Tunnel-Type" and "Tunnel-Medium-Type" are both integers, but their values are serialized as strings:
>
> "Tunnel-Type": {"type": "integer", "value": ["VLAN"]},
> "Tunnel-Medium-Type": {"type": "integer", "value": ["IEEE-802"]}
>


Which version are you running? Where is the debug output? Please, keep in mind https://wiki.freeradius.org/guide/Users-Mailing-List <https://wiki.freeradius.org/guide/Users-Mailing-List>


> This behavior makes it difficult to write a parser without knowing the numeric value of "VLAN" and "IEEE-802". Is there a configuration parameter that prevents the rlm_rest module from translating attribute values?
>
> Thanks in advance,
> Michael-
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: [rlm_rest] do not translate attribute values

Michael Schneider
Hi Jorge

> On 17 Dec 2020, at 17:57, Jorge Pereira <[hidden email]> wrote:
>
>>
>> On 17 Dec 2020, at 09:25, Michael Schneider <[hidden email]> wrote:
>>
>> ...
>
>
> Which version are you running? Where is the debug output? Please, keep in mind https://wiki.freeradius.org/guide/Users-Mailing-List <https://wiki.freeradius.org/guide/Users-Mailing-List>

Sorry, my question was a bit unclear.

I am using FreeRADIUS version 3.0.21. The server works as expected, but the generated REST request is weird in my opinion. The two attributes "Tunnel-Type (64)" and "Tunnel-Medium-Type (65)" are particularly special. The value type of them is an integer and this is also signaled via REST, but the value provided is the string representation of the integer.


Currently signaled via REST (FreeRADIUS 3.0.21):
Debug: (10) rest: Encoding attribute "Tunnel-Type"
Debug: (10) rest:   Type   : integer
Debug: (10) rest:   Length : 3
Debug: (10) rest:   Value  : "VLAN"
Debug: (10) rest: Encoding attribute "Tunnel-Medium-Type"
Debug: (10) rest:   Type   : integer
Debug: (10) rest:   Length : 8
Debug: (10) rest:   Value  : "IEEE-802"
...
Debug: (32) rest: JSON Data: {"Tunnel-Type":{"type":"integer","value":["VLAN"]},"Tunnel-Medium-Type":{"type":"integer","value":["IEEE-802"]}}


What I would expect:
Debug: (10) rest: Encoding attribute "Tunnel-Type"
Debug: (10) rest:   Type   : integer
Debug: (10) rest:   Length : 3
Debug: (10) rest:   Value  : "13"
Debug: (10) rest: Encoding attribute "Tunnel-Medium-Type"
Debug: (10) rest:   Type   : integer
Debug: (10) rest:   Length : 8
Debug: (10) rest:   Value  : "6"
...
Debug: (32) rest: JSON Data: {"Tunnel-Type":{"type":"integer","value":[13]},"Tunnel-Medium-Type":{"type":"integer","value":[6]}}


I am not sure if this behavior was intended by Arran Cudbard-Bell.

- Michael
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

smime.p7s (5K) Download Attachment
| Threaded
Open this post in threaded view
|

Re: [rlm_rest] do not translate attribute values

Alan DeKok-2
On Dec 17, 2020, at 3:11 PM, Michael Schneider <[hidden email]> wrote:
> I am using FreeRADIUS version 3.0.21. The server works as expected, but the generated REST request is weird in my opinion. The two attributes "Tunnel-Type (64)" and "Tunnel-Medium-Type (65)" are particularly special. The value type of them is an integer and this is also signaled via REST, but the value provided is the string representation of the integer.

  I've pushed a fix for v3.0.x.  It always prints the integer value, and does not print the name.

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: [rlm_rest] do not translate attribute values

Matthew Newton-3

On 17/12/2020 20:47, Alan DeKok wrote:
> On Dec 17, 2020, at 3:11 PM, Michael Schneider <[hidden email]> wrote:
>> I am using FreeRADIUS version 3.0.21. The server works as expected, but the generated REST request is weird in my opinion. The two attributes "Tunnel-Type (64)" and "Tunnel-Medium-Type (65)" are particularly special. The value type of them is an integer and this is also signaled via REST, but the value provided is the string representation of the integer.
>
>    I've pushed a fix for v3.0.x.  It always prints the integer value, and does not print the name.

In v4 this is configurable (in the code at least, possibly not yet in
rlm_rest). But the thing is the "type" is the RADIUS attribute type,
whereas the value contains the useful human-readable string value.
"type" doesn't mean the JSON type of the following value.

If it's an integer then it'll be a JSON integer (i.e. not
double-quoted). Relying on the value of "type" to know what JSON type it
is should be unnecessary; a JSON parser that needs to be told the type
is "integer" is broken.

The problem at the moment with no config option is that not everyone's
going to be happy. Personally I'd think that the original behaviour here
was most useful for most people, who wouldn't have an immediate clue
what Tunnel-Type 13 is - but "VLAN" makes a lot more sense.

Hopefully changing it won't break any existing deployments...

--
Matthew
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: [rlm_rest] do not translate attribute values

Michael Schneider
In reply to this post by Alan DeKok-2
Hi Alan

> On 17 Dec 2020, at 21:47, Alan DeKok <[hidden email]> wrote:
>
> On Dec 17, 2020, at 3:11 PM, Michael Schneider <[hidden email]> wrote:
>> I am using FreeRADIUS version 3.0.21. The server works as expected, but the generated REST request is weird in my opinion. The two attributes "Tunnel-Type (64)" and "Tunnel-Medium-Type (65)" are particularly special. The value type of them is an integer and this is also signaled via REST, but the value provided is the string representation of the integer.
>
>  I've pushed a fix for v3.0.x.  It always prints the integer value, and does not print the name.

Thanks for the fix, but unfortunately it has no effect on the generated JSON.

- Michael
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: [rlm_rest] do not translate attribute values

Michael Schneider
In reply to this post by Matthew Newton-3
Hi Matthew

> On 18 Dec 2020, at 00:03, Matthew Newton <[hidden email]> wrote:
>
> On 17/12/2020 20:47, Alan DeKok wrote:
>> On Dec 17, 2020, at 3:11 PM, Michael Schneider <[hidden email]> wrote:
>>> I am using FreeRADIUS version 3.0.21. The server works as expected, but the generated REST request is weird in my opinion. The two attributes "Tunnel-Type (64)" and "Tunnel-Medium-Type (65)" are particularly special. The value type of them is an integer and this is also signaled via REST, but the value provided is the string representation of the integer.
>>   I've pushed a fix for v3.0.x.  It always prints the integer value, and does not print the name.
>
> In v4 this is configurable (in the code at least, possibly not yet in rlm_rest). But the thing is the "type" is the RADIUS attribute type, whereas the value contains the useful human-readable string value. "type" doesn't mean the JSON type of the following value.
>
> If it's an integer then it'll be a JSON integer (i.e. not double-quoted). Relying on the value of "type" to know what JSON type it is should be unnecessary; a JSON parser that needs to be told the type is "integer" is broken.

The JSON parser is not the problem. Our REST endpoint is written in Java and we have created classes for all the RADIUS attributes we use. The radius attribute "Tuennel-Type" expects an integer value, but the parser returns a string. So the problem is that the received value type does not match the expected value type. To avoid this problem, we need to go further and understand the value of each attribute and then accept an integer or its string representation.

> The problem at the moment with no config option is that not everyone's going to be happy. Personally I'd think that the original behaviour here was most useful for most people, who wouldn't have an immediate clue what Tunnel-Type 13 is - but "VLAN" makes a lot more sense.
>
> Hopefully changing it won't break any existing deployments...

I fully agree that "VLAN" is much more readable than 13, but in my opinion rlm_rest is a technical interface and therefore must be technically correct and not human readable. I think a configuration option is needed, otherwise this is a breaking change. If desired, I can try to create an appropriate PR.

- Michael
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: [rlm_rest] do not translate attribute values

arr2036


> On Dec 17, 2020, at 5:42 PM, Michael Schneider <[hidden email]> wrote:
>
> Hi Matthew
>
>> On 18 Dec 2020, at 00:03, Matthew Newton <[hidden email]> wrote:
>>
>> On 17/12/2020 20:47, Alan DeKok wrote:
>>> On Dec 17, 2020, at 3:11 PM, Michael Schneider <[hidden email]> wrote:
>>>> I am using FreeRADIUS version 3.0.21. The server works as expected, but the generated REST request is weird in my opinion. The two attributes "Tunnel-Type (64)" and "Tunnel-Medium-Type (65)" are particularly special. The value type of them is an integer and this is also signaled via REST, but the value provided is the string representation of the integer.
>>>  I've pushed a fix for v3.0.x.  It always prints the integer value, and does not print the name.
I've reverted it.  Breaking changes in point releases are not appropriate.  This would break the majority of the users of rlm_rest who inspect the values of enumeration attributes.

>> The problem at the moment with no config option is that not everyone's going to be happy. Personally I'd think that the original behaviour here was most useful for most people, who wouldn't have an immediate clue what Tunnel-Type 13 is - but "VLAN" makes a lot more sense.
>>
>> Hopefully changing it won't break any existing deployments...
>
> I fully agree that "VLAN" is much more readable than 13, but in my opinion rlm_rest is a technical interface

Following that logic we should just send across attribute numbers instead of providing the dictionary names?

> and therefore must be technically correct and not human readable. I think a configuration option is needed, otherwise this is a breaking change. If desired, I can try to create an appropriate PR.

Feel free.  It should be a relatively simple change.

-Arran

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

signature.asc (849 bytes) Download Attachment
| Threaded
Open this post in threaded view
|

Re: [rlm_rest] do not translate attribute values

Alan DeKok-2
On Dec 17, 2020, at 10:23 PM, Arran Cudbard-Bell <[hidden email]> wrote:
> I've reverted it.  Breaking changes in point releases are not appropriate.  This would break the majority of the users of rlm_rest who inspect the values of enumeration attributes.

  Sure.

  The other argument here is that even if Tunnel-Medium-Type is of type "integer", the values of those integers have no meaning.  You're not adding together the values.  Instead, the names of the values have meaning.

  So the recommendation is for the REST back-end to *not* parse Tunnel-Medium-Type as "integer".  Because that doesn't give you any information.

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html