<div dir="ltr"><div>You're right the authentication is not being proxied to the other server but only the authorization.</div><div><br></div><div>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:</div>
<div><br></div><div><font face="courier new, monospace"># Function to handle authenticate</font></div><div><font face="courier new, monospace">sub authenticate {</font></div><div><font face="courier new, monospace"><span class="" style="white-space:pre">    </span># For debugging purposes only</font></div>
<div><font face="courier new, monospace"><span class="" style="white-space:pre">        </span>&log_request_attributes;</font></div><div><font face="courier new, monospace"><span class="" style="white-space:pre">      </span>return RLM_MODULE_OK;</font></div>
<div><font face="courier new, monospace">}</font></div><div><font face="courier new, monospace"><br></font></div><div><br></div><div>I will look into the new rest module mentioned by Arran. Thank you for the information.</div>
<div><br></div><div>Regards,</div><div>Shurbann Martes</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jan 3, 2014 at 5:03 PM, Alan DeKok <span dir="ltr"><<a href="mailto:aland@deployingradius.com" target="_blank">aland@deployingradius.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">Shurbann Martes wrote:<br>
> What' we're trying to accomplish here is to map (this was the typo<br>
> ammped in the earlier message) every RADIUS call to an HTTP call on<br>
> another system. We did not find any correct solution for this other that<br>
> using the Perl module.<br>
<br>
</div>  If you use v3, the rest module should work.  See Arran's post.<br>
<div class="im"><br>
> That's the reason we start using Perl module. So<br>
> for example a Access-Request will call a URL using HTTP GET on the other<br>
> system, with HTTP parameters containing the necessary info, i.e. user,<br>
> Called-Station-Id etc. Based on the response i.e. HTTP status response<br>
> 403, 401 or 202 received from this system, we will send a Access-Accept<br>
> or Access-Reject back to the NAS. This is working OK, right now using<br>
> the Auth-Type = Perl.<br>
<br>
</div>  This is not the recommended approach.  FreeRADIUS is an authentication<br>
server.  You should have it do authentication.  Other systems used by<br>
FreeRADIUS are databases.  Any other design is almost always wrong.<br>
<br>
  You can use the Perl module in the "authorize" section.  Have it<br>
create an attribute 'allowed = yes / no".  See raddb/dictionary for<br>
examples of creating a new attribute to hold this value.<br>
<br>
  Then, use FreeRADIUS to decide whether or not the user is authenticated.<br>
<div class="im"><br>
> However with the introduction of the EAP-SIM module as part of the<br>
> protocol we're going to use, I was wondering if I can have FreeRADIUS<br>
> configured better, by trying not to use the Auth-Type. So I'm trying to<br>
> find out what the correct way of doing this is.<br>
<br>
</div>  Make authorization decisions as above.  What you're describing above<br>
is whether or not the user is *authorized* to use the service.  Since<br>
you didn't check passwords, you have no idea whether or not he's been<br>
*authenticated*.<br>
<br>
  Many authentication protocols require complex back and forth work.<br>
Don't re-do all of that in Perl.  Instead, let FreeRADIUS do<br>
authentication.  Your script should do authorization.<br>
<div class="HOEnZb"><div class="h5"><br>
  Alan DeKok.<br>
-<br>
List info/subscribe/unsubscribe? See <a href="http://www.freeradius.org/list/users.html" target="_blank">http://www.freeradius.org/list/users.html</a><br>
</div></div></blockquote></div><br></div>