Enable Perl module in combination with EAP/SIM module
Hi list, Just wondering if there is a way to enable the Perl module to work without changing the users files as described here http://wiki.freeradius.org/modules/Rlm_perl. This page describe that to enable the Perl module the users file needs to be changed by adding the following line: DEFAULT Auth-Type = Perl Fall-Through = yes In many places (http://wiki.freeradius.org/config/Auth%20Type) I'm reading that it is not a good idea to intervene by setting the Auth-Type manually, but still on the wiki page of rlm_perl this is being described as the way to enable the Perl module to work. Until now I've been using the Perl module alone to authenticate/authorize and changing the users file works great. But now I need to combine EAP/SIM module with Perl module. So when the message contains EAP/SIM attributes it needs to authenticate using EAP module, else it needs to fallback to the Perl one. With the users script changed as described on the perl_module page the EAP module won't work and if I don't change the users it will use EAP/SIM module, but Perl module will fail. So intervening here looks like is causing modules not to work properly Which strategy needs one to follow when using the Perl script in combination with EAP/SIM. Just want to be sure that I'm using the proper way to enable the Perl module, without intervening in the Auth-Type. Thanks you for your time. If you need me to add the default and the users file, just let me know. Regards, Shurbann Martes
What's the Perl module doing for you? Just call it in the relevant configuration section (eg authorise or authenticate section of relevant virtual server) Alan -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Shurbann Martes wrote
Just wondering if there is a way to enable the Perl module to work without changing the users files as described here http://wiki.freeradius.org/modules/Rlm_perl.
Yes. Just list "perl" in "authorize". Each section is independent. You do NOT need to run "perl" in "authenticate"
In many places (http://wiki.freeradius.org/config/Auth%20Type) I'm reading that it is not a good idea to intervene by setting the Auth-Type manually, but still on the wiki page of rlm_perl this is being described as the way to enable the Perl module to work.
No, that's the way to get "perl" run in the "authenticate" section.
Until now I've been using the Perl module alone to authenticate/authorize and changing the users file works great.
I would VERY much suggest that you don't run "perl" in "authenticate". There is almost always no need for it.
But now I need to combine EAP/SIM module with Perl module. So when the message contains EAP/SIM attributes it needs to authenticate using EAP module, else it needs to fallback to the Perl one.
You can key off of EAP-Message. If it exists, don't set Auth-Type = Perl. This probably should be done in "unlang", instead of in the "users" file.
With the users script changed as described on the perl_module page the EAP module won't work and if I don't change the users it will use EAP/SIM module, but Perl module will fail. So intervening here looks like is causing modules not to work properly
Delete that entry from the "users" file.
Which strategy needs one to follow when using the Perl script in combination with EAP/SIM. Just want to be sure that I'm using the proper way to enable the Perl module, without intervening in the Auth-Type.
There is no "proper" way. It all depends on what you need. If you don't need "perl" in "authenticate", don't set Auth-Type. Alan DeKok.
Hi Alan, Thank your for the response. All the RADIUS PDU's need to be ammped to the HTTP API of a AAA server. So we're using the Perl module to do the HTTP calls. That's why we're using perl in authenticate. If there is another way to proxy HTTP calls please advise. Regards, Shurbann Martes On Fri, Jan 3, 2014 at 10:47 AM, Alan DeKok <aland@deployingradius.com>wrote:
Shurbann Martes wrote
Just wondering if there is a way to enable the Perl module to work without changing the users files as described here http://wiki.freeradius.org/modules/Rlm_perl.
Yes. Just list "perl" in "authorize". Each section is independent. You do NOT need to run "perl" in "authenticate"
In many places (http://wiki.freeradius.org/config/Auth%20Type) I'm reading that it is not a good idea to intervene by setting the Auth-Type manually, but still on the wiki page of rlm_perl this is being described as the way to enable the Perl module to work.
No, that's the way to get "perl" run in the "authenticate" section.
Until now I've been using the Perl module alone to authenticate/authorize and changing the users file works great.
I would VERY much suggest that you don't run "perl" in "authenticate". There is almost always no need for it.
But now I need to combine EAP/SIM module with Perl module. So when the message contains EAP/SIM attributes it needs to authenticate using EAP module, else it needs to fallback to the Perl one.
You can key off of EAP-Message. If it exists, don't set Auth-Type = Perl.
This probably should be done in "unlang", instead of in the "users" file.
With the users script changed as described on the perl_module page the EAP module won't work and if I don't change the users it will use EAP/SIM module, but Perl module will fail. So intervening here looks like is causing modules not to work properly
Delete that entry from the "users" file.
Which strategy needs one to follow when using the Perl script in combination with EAP/SIM. Just want to be sure that I'm using the proper way to enable the Perl module, without intervening in the Auth-Type.
There is no "proper" way. It all depends on what you need. If you don't need "perl" in "authenticate", don't set Auth-Type.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Shurbann Martes wrote:
All the RADIUS PDU's need to be ammped to the HTTP API of a AAA server.
I'm not sure what that means.
So we're using the Perl module to do the HTTP calls. That's why we're using perl in authenticate. If there is another way to proxy HTTP calls please advise.
You're assuming I already understand your system, and then describing it using as fews words as possible. Stop it. You're giving me every reason to ignore you. If you don't care enough to write useful questions, I don't care enough to write useful answers. WHAT is the HTTP API doing? "ammped" isn't an English word. WHAT is the Perl code doing? HTTP calls? That's nice.. WHAT is it doing with those HTTP calls? Sending magic pixies? HOW is it using the RADIUS data to make those HTTP calls? And "proxy HTTP calls" makes zero sense. FreeRADIUS isn't an HTTP server. So it can't proxy HTTP. Right now, all I can tell is that you know how to use the words "RADIUS", "Perl", and "HTTP" in a sentence. That's nice, but not particularly useful. Alan DeKok.
You're right when you're so deep into a problem you assume that the issue at hand is clear to everyone without sounding to cryptic. Let me try to explain the problem at hand little bit more. I'm trying not to bother you much with the details, but still be as clear as possible. What' we're trying to accomplish here is to map (this was the typo ammped in the earlier message) every RADIUS call to an HTTP call on another system. We did not find any correct solution for this other that using the Perl module. That's the reason we start using Perl module. So for example a Access-Request will call a URL using HTTP GET on the other system, with HTTP parameters containing the necessary info, i.e. user, Called-Station-Id etc. Based on the response i.e. HTTP status response 403, 401 or 202 received from this system, we will send a Access-Accept or Access-Reject back to the NAS. This is working OK, right now using the Auth-Type = Perl. However with the introduction of the EAP-SIM module as part of the protocol we're going to use, I was wondering if I can have FreeRADIUS configured better, by trying not to use the Auth-Type. So I'm trying to find out what the correct way of doing this is. Regards, Shurbann Martes On Fri, Jan 3, 2014 at 12:33 PM, Alan DeKok <aland@deployingradius.com>wrote:
Shurbann Martes wrote:
All the RADIUS PDU's need to be ammped to the HTTP API of a AAA server.
I'm not sure what that means.
So we're using the Perl module to do the HTTP calls. That's why we're using perl in authenticate. If there is another way to proxy HTTP calls please advise.
You're assuming I already understand your system, and then describing it using as fews words as possible. Stop it. You're giving me every reason to ignore you. If you don't care enough to write useful questions, I don't care enough to write useful answers.
WHAT is the HTTP API doing? "ammped" isn't an English word.
WHAT is the Perl code doing? HTTP calls? That's nice.. WHAT is it doing with those HTTP calls? Sending magic pixies? HOW is it using the RADIUS data to make those HTTP calls?
And "proxy HTTP calls" makes zero sense. FreeRADIUS isn't an HTTP server. So it can't proxy HTTP.
Right now, all I can tell is that you know how to use the words "RADIUS", "Perl", and "HTTP" in a sentence. That's nice, but not particularly useful.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 3 Jan 2014, at 18:32, Shurbann Martes <shurbann@gmail.com> wrote:
You're right when you're so deep into a problem you assume that the issue at hand is clear to everyone without sounding to cryptic. Let me try to explain the problem at hand little bit more. I'm trying not to bother you much with the details, but still be as clear as possible.
What' we're trying to accomplish here is to map (this was the typo ammped in the earlier message) every RADIUS call to an HTTP call on another system. We did not find any correct solution for this other that using the Perl module.
Um...
That's the reason we start using Perl module. So for example a Access-Request will call a URL using HTTP GET on the other system, with HTTP parameters containing the necessary info, i.e. user, Called-Station-Id etc. Based on the response i.e. HTTP status response 403, 401 or 202 received from this system, we will send a Access-Accept or Access-Reject back to the NAS. This is working OK, right now using the Auth-Type = Perl.
The REST module does exactly this (rlm_rest). It's included in 3.0.0. It will be *SIGNIFICANTLY* faster than Perl, and is written in such a way to allow libcurl to do connection caching so you don't have the TCP connection setup/teardown after every request.
However with the introduction of the EAP-SIM module as part of the protocol we're going to use, I was wondering if I can have FreeRADIUS configured better, by trying not to use the Auth-Type. So I'm trying to find out what the correct way of doing this is.
IIRC (but you'll need to test), that if you call rlm_eap in post-auth reject {} it'll generate the correct eap failure message. Which means if the user is rejected by the HTTP server, FreeRADIUS will send an EAP-Failure with the Access-Reject. Call rest/perl in authorize. Call eap in authorize (it will set Auth-Type eap) Leave auth-type eap in authenticate. Call eap in post-auth reject {}. Simple. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Thank you for pointing out the rest module. At this moment we are on the 2.2.x version, but we will consider to move to version 3.0.0. Regards, Shurbann Martes On Fri, Jan 3, 2014 at 3:13 PM, Arran Cudbard-Bell < a.cudbardb@freeradius.org> wrote:
On 3 Jan 2014, at 18:32, Shurbann Martes <shurbann@gmail.com> wrote:
You're right when you're so deep into a problem you assume that the issue at hand is clear to everyone without sounding to cryptic. Let me try to explain the problem at hand little bit more. I'm trying not to bother you much with the details, but still be as clear as possible.
What' we're trying to accomplish here is to map (this was the typo ammped in the earlier message) every RADIUS call to an HTTP call on another system. We did not find any correct solution for this other that using the Perl module.
Um...
That's the reason we start using Perl module. So for example a Access-Request will call a URL using HTTP GET on the other system, with HTTP parameters containing the necessary info, i.e. user, Called-Station-Id etc. Based on the response i.e. HTTP status response 403, 401 or 202 received from this system, we will send a Access-Accept or Access-Reject back to the NAS. This is working OK, right now using the Auth-Type = Perl.
The REST module does exactly this (rlm_rest). It's included in 3.0.0. It will be *SIGNIFICANTLY* faster than Perl, and is written in such a way to allow libcurl to do connection caching so you don't have the TCP connection setup/teardown after every request.
However with the introduction of the EAP-SIM module as part of the protocol we're going to use, I was wondering if I can have FreeRADIUS configured better, by trying not to use the Auth-Type. So I'm trying to find out what the correct way of doing this is.
IIRC (but you'll need to test), that if you call rlm_eap in post-auth reject {} it'll generate the correct eap failure message. Which means if the user is rejected by the HTTP server, FreeRADIUS will send an EAP-Failure with the Access-Reject.
Call rest/perl in authorize.
Call eap in authorize (it will set Auth-Type eap)
Leave auth-type eap in authenticate.
Call eap in post-auth reject {}.
Simple.
Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Shurbann Martes wrote:
What' we're trying to accomplish here is to map (this was the typo ammped in the earlier message) every RADIUS call to an HTTP call on another system. We did not find any correct solution for this other that using the Perl module.
If you use v3, the rest module should work. See Arran's post.
That's the reason we start using Perl module. So for example a Access-Request will call a URL using HTTP GET on the other system, with HTTP parameters containing the necessary info, i.e. user, Called-Station-Id etc. Based on the response i.e. HTTP status response 403, 401 or 202 received from this system, we will send a Access-Accept or Access-Reject back to the NAS. This is working OK, right now using the Auth-Type = Perl.
This is not the recommended approach. FreeRADIUS is an authentication server. You should have it do authentication. Other systems used by FreeRADIUS are databases. Any other design is almost always wrong. You can use the Perl module in the "authorize" section. Have it create an attribute 'allowed = yes / no". See raddb/dictionary for examples of creating a new attribute to hold this value. Then, use FreeRADIUS to decide whether or not the user is authenticated.
However with the introduction of the EAP-SIM module as part of the protocol we're going to use, I was wondering if I can have FreeRADIUS configured better, by trying not to use the Auth-Type. So I'm trying to find out what the correct way of doing this is.
Make authorization decisions as above. What you're describing above is whether or not the user is *authorized* to use the service. Since you didn't check passwords, you have no idea whether or not he's been *authenticated*. Many authentication protocols require complex back and forth work. Don't re-do all of that in Perl. Instead, let FreeRADIUS do authentication. Your script should do authorization. Alan DeKok.
You're right the authentication is not being proxied to the other server but only the authorization. The authentication in the script, right now is always sending OK, since we're relying only on the authorization part to decide whether or not we should grand Access. Is their a penalty that we're paying for this? Not sure yet, will have to look into this: # Function to handle authenticate sub authenticate { # For debugging purposes only &log_request_attributes; return RLM_MODULE_OK; } I will look into the new rest module mentioned by Arran. Thank you for the information. Regards, Shurbann Martes On Fri, Jan 3, 2014 at 5:03 PM, Alan DeKok <aland@deployingradius.com>wrote:
Shurbann Martes wrote:
What' we're trying to accomplish here is to map (this was the typo ammped in the earlier message) every RADIUS call to an HTTP call on another system. We did not find any correct solution for this other that using the Perl module.
If you use v3, the rest module should work. See Arran's post.
That's the reason we start using Perl module. So for example a Access-Request will call a URL using HTTP GET on the other system, with HTTP parameters containing the necessary info, i.e. user, Called-Station-Id etc. Based on the response i.e. HTTP status response 403, 401 or 202 received from this system, we will send a Access-Accept or Access-Reject back to the NAS. This is working OK, right now using the Auth-Type = Perl.
This is not the recommended approach. FreeRADIUS is an authentication server. You should have it do authentication. Other systems used by FreeRADIUS are databases. Any other design is almost always wrong.
You can use the Perl module in the "authorize" section. Have it create an attribute 'allowed = yes / no". See raddb/dictionary for examples of creating a new attribute to hold this value.
Then, use FreeRADIUS to decide whether or not the user is authenticated.
However with the introduction of the EAP-SIM module as part of the protocol we're going to use, I was wondering if I can have FreeRADIUS configured better, by trying not to use the Auth-Type. So I'm trying to find out what the correct way of doing this is.
Make authorization decisions as above. What you're describing above is whether or not the user is *authorized* to use the service. Since you didn't check passwords, you have no idea whether or not he's been *authenticated*.
Many authentication protocols require complex back and forth work. Don't re-do all of that in Perl. Instead, let FreeRADIUS do authentication. Your script should do authorization.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Shurbann Martes wrote:
You're right the authentication is not being proxied to the other server but only the authorization.
OK.
The authentication in the script, right now is always sending OK, since we're relying only on the authorization part to decide whether or not we should grand Access. Is their a penalty that we're paying for this?
Yes. It's not necessary. Delete it. Alan DeKok.
On 3 Jan 2014, at 15:58, Shurbann Martes <shurbann@gmail.com> wrote:
Hi Alan,
Thank your for the response.
All the RADIUS PDU's need to be ammped to the HTTP API of a AAA server. So we're using the Perl module to do the HTTP calls. That's why we're using perl in authenticate. If there is another way to proxy HTTP calls please advise.
There's the REST module. But you'll need some flexibility on the API side. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
participants (4)
-
Alan Buxey -
Alan DeKok -
Arran Cudbard-Bell -
Shurbann Martes