I know you guys are very busy helping the rest but I hope you can help me with this. I would like freeradius to authenticate with 3rd party application via REST API. I do have the configuration like below. connect_uri = "http://10.18.6.22:8081/apps/" authenticate { uri = "${..connect_uri}/user/%{User-Name}/%{User-Password}" method = "get" } Problem is that I do not know what to be included in the request and response for every authenticate, authorize, post-auth, and accounting. For the response, I just include the HTTP status is sufficient for authentication? How about the response for authorize, post-auth, and accounting? If the freeRadius is configured to use RESTful API, does other post-auth, authorize, and accounting can be use with mysql so that only authentication is using rest?
On Dec 17, 2018, at 11:15 PM, Daniel Kong <daniel.kongyh@gmail.com> wrote:
I know you guys are very busy helping the rest but I hope you can help me with this. I would like freeradius to authenticate with 3rd party application via REST API. I do have the configuration like below.
connect_uri = "http://10.18.6.22:8081/apps/" authenticate { uri = "${..connect_uri}/user/%{User-Name}/%{User-Password}" method = "get" }
OK...
Problem is that I do not know what to be included in the request and response for every authenticate, authorize, post-auth, and accounting. For the response, I just include the HTTP status is sufficient for authentication? How about the response for authorize, post-auth, and accounting?
You don't need to include anything in the response. The documentation describes how the module works and what it does. FreeRADIUS treats the REST API as just another database. There's no "requirement" to put anything into SQL, so there's no requirement to put anything in REST.
If the freeRadius is configured to use RESTful API, does other post-auth, authorize, and accounting can be use with mysql so that only authentication is using rest?
Yes. You just list "rest" in the authenticate section, and "sql" elsewhere. Alan DeKok.
Thanks for the feedback, Alan. I have more questions to ask regarding the REST authentication. How does the freeRadius know that when to let the user to gain access to the resources after invoke REST authentication? Does it rely on the REST response http status? Eg. if the 3rd party application returns a http status 200 means that the user is authenticated and able to use the resource. However if the REST response returns a http status 401 means that he/she is unauthorized. Does the freeRadius interpret it this way? In order to use REST authentication only while the others like post-auth, authorize, and accounting using the sql, I only need to configure the REST for authentication. So my configuration would look like this? I just comment off post-auth, authorize, and accounting. Correct me if I am wrong. rest { tls { ... } authentication { } #authorize { #} #post-auth { #} #accounting { #} pool { ... } } So after authenticate is successful, freeRadius will do insertion of record to radpostauth and radacct table by itself? Our current usage of freeRadius is with mySQL. So we will insert record to radcheck and radreply table while the rest of the table will be handled by freeRadius. Now if we are using the REST for authentication, do we still need to insert record to radcheck and radreply? Do we still rely on the 'Auth-Type' in the radcheck table? Daniel. On Tue, Dec 18, 2018 at 7:57 PM Alan DeKok <aland@deployingradius.com> wrote:
On Dec 17, 2018, at 11:15 PM, Daniel Kong <daniel.kongyh@gmail.com> wrote:
I know you guys are very busy helping the rest but I hope you can help me with this. I would like freeradius to authenticate with 3rd party application via REST API. I do have the configuration like below.
connect_uri = "http://10.18.6.22:8081/apps/" authenticate { uri = "${..connect_uri}/user/%{User-Name}/%{User-Password}" method = "get" }
OK...
Problem is that I do not know what to be included in the request and response for every authenticate, authorize, post-auth, and accounting. For the response, I just include the HTTP status is sufficient for authentication? How about the response for authorize, post-auth, and accounting?
You don't need to include anything in the response. The documentation describes how the module works and what it does.
FreeRADIUS treats the REST API as just another database. There's no "requirement" to put anything into SQL, so there's no requirement to put anything in REST.
If the freeRadius is configured to use RESTful API, does other post-auth, authorize, and accounting can be use with mysql so that only authentication is using rest?
Yes. You just list "rest" in the authenticate section, and "sql" elsewhere.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Dec 18, 2018, at 11:01 PM, Daniel Kong <daniel.kongyh@gmail.com> wrote:
Thanks for the feedback, Alan. I have more questions to ask regarding the REST authentication. How does the freeRadius know that when to let the user to gain access to the resources after invoke REST authentication?
The server doesn't "let the user gain access to resources". The server *authenticates* the user. By sending an Access-Accept with various attributes in it. It's important to understand how it works. If you have misconceptions about how the server works, then you won't be asking the right questions, and you won't be doing the right things.
Does it rely on the REST response http status? Eg. if the 3rd party application returns a http status 200 means that the user is authenticated and able to use the resource. However if the REST response returns a http status 401 means that he/she is unauthorized. Does the freeRadius interpret it this way?
Go read raddb/mods-available/rest. This *is* documented. The configuration file tells you how the http status return codes map to the FreeRADIUS codes that are used to process packets. Then... read the FreeRADIUS documentation to see how it works. I suggest starting here: https://networkradius.com/freeradius-documentation/ Read the "technical guide" to get a good overview of how the server works.
In order to use REST authentication only while the others like post-auth, authorize, and accounting using the sql, I only need to configure the REST for authentication. So my configuration would look like this? I just comment off post-auth, authorize, and accounting. Correct me if I am wrong.
You can read the documentation to see how the rest module works. Your questions are answered there.
So after authenticate is successful, freeRadius will do insertion of record to radpostauth and radacct table by itself?
No. This isn't magic. The sql module puts data into radpostauth and radacct... if you configure the server to use the SQL module in "post-auth" and "accounting". The default configuration files go through this in great detail.
Our current usage of freeRadius is with mySQL. So we will insert record to radcheck and radreply table while the rest of the table will be handled by freeRadius.
I have no idea what that means.
Now if we are using the REST for authentication, do we still need to insert record to radcheck and radreply? Do we still rely on the 'Auth-Type' in the radcheck table?
The radcheck and radreply tables are used by the SQL module. If you're not using the SQL module, then those tables aren't used. Your questions seem to be coming from a mindset that the server is magic, and magically "knows" how to do things. It isn't. It has a lot going on, and a lot of configuration files. But in the end it's just a whole bunch of simple things put together in gradually more complex ways. If you want to use radcheck / radreply, configure the SQL module. And be sure that the SQL module is listed in the virtual server. See sites-available/default for many, many, examples. Go read the technical guide I think many of your misconceptions are addressed there. Alan DeKok.
Hi, thanks for the guidance. However, I encounter a problem in the rest basic http authentication even though I have provided in the configuration file. connect_uri = "http://10.18.6.22:8081/apps" authenticate { uri = "${..connect_uri}/user/%{User-Name}/%{User-Password}" method = "get" force_to = "json" require_auth = yes auth = "basic" username = "test" password = "password123" tls = ${..tls} } I have added the following lines to the default configuration file. authorize { if (&User-Password) { update control { Auth-Type := 'rest' } } } authenticate { rest } And here is my radius output (3) Received Access-Request Id 53 from 127.0.0.1:42150 to 127.0.0.1:1812 length 47 (3) User-Name = "user1" (3) User-Password = "password1" (3) # Executing section authorize from file /usr/local/etc/raddb/sites-enabled/default (3) authorize { (3) policy filter_username { (3) if (&User-Name) { (3) if (&User-Name) -> TRUE (3) if (&User-Name) { (3) if (&User-Name =~ / /) { (3) if (&User-Name =~ / /) -> FALSE (3) if (&User-Name =~ /@[^@]*@/ ) { (3) if (&User-Name =~ /@[^@]*@/ ) -> FALSE (3) if (&User-Name =~ /\.\./ ) { (3) if (&User-Name =~ /\.\./ ) -> FALSE (3) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/)) { (3) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/)) -> FALSE (3) if (&User-Name =~ /\.$/) { (3) if (&User-Name =~ /\.$/) -> FALSE (3) if (&User-Name =~ /@\./) { (3) if (&User-Name =~ /@\./) -> FALSE (3) } # if (&User-Name) = notfound (3) } # policy filter_username = notfound (3) [preprocess] = ok (3) [chap] = noop (3) [mschap] = noop (3) [digest] = noop (3) suffix: Checking for suffix after "@" (3) suffix: No '@' in User-Name = "user1", looking up realm NULL (3) suffix: No such realm "NULL" (3) [suffix] = noop (3) eap: No EAP-Message, not doing EAP (3) [eap] = noop (3) [files] = noop (3) [expiration] = noop (3) [logintime] = noop (3) if (&User-Password) { (3) if (&User-Password) -> TRUE (3) if (&User-Password) { (3) update control { (3) Auth-Type := rest (3) } # update control = noop (3) } # if (&User-Password) = noop (3) } # authorize = ok (3) Found Auth-Type = rest (3) # Executing group from file /usr/local/etc/raddb/sites-enabled/default (3) authenticate { rlm_rest (rest): Closing connection (6): Hit idle_timeout, was idle for 134 seconds rlm_rest (rest): You probably need to lower "min" rlm_rest (rest): Closing connection (1): Hit idle_timeout, was idle for 111 seconds rlm_rest (rest): You probably need to lower "min" rlm_rest (rest): Closing connection (7): Hit idle_timeout, was idle for 111 seconds rlm_rest (rest): You probably need to lower "min" rlm_rest (rest): 0 of 0 connections in use. You may need to increase "spare" rlm_rest (rest): Opening additional connection (8), 1 of 32 pending slots used rlm_rest (rest): Connecting to "http://10.18.6.22:8081/apps" rlm_rest (rest): Reserved connection (8) (3) rest: Expanding URI components (3) rest: EXPAND http://10.18.6.22:8081 (3) rest: --> http://10.18.6.22:8081 (3) rest: EXPAND /apps/user/%{User-Name}/%{User-Password} (3) rest: --> /apps/user/user1/password1 (3) rest: Sending HTTP GET to " http://10.18.6.22:8081/apps/user/user1/password1" (3) rest: Processing response header (3) rest: Status : 401 (Unauthorized) (3) rest: Type : json (application/json) (3) rest: Parsing attribute "result" (3) rest: WARNING: Failed parsing attribute: Invalid vendor name in attribute name "result", skipping... (3) rest: Parsing attribute "message" (3) rest: WARNING: Failed parsing attribute: Invalid vendor name in attribute name "message", skipping... rlm_rest (rest): Released connection (8) Need 2 more connections to reach min connections (3) rlm_rest (rest): Opening additional connection (9), 1 of 31 pending slots used rlm_rest (rest): Connecting to "http://10.18.6.22:8081/apps" (3) [rest] = reject (3) } # authenticate = reject (3) Failed to authenticate the user (3) Using Post-Auth-Type Reject (3) # Executing group from file /usr/local/etc/raddb/sites-enabled/default (3) Post-Auth-Type REJECT { (3) attr_filter.access_reject: EXPAND %{User-Name} (3) attr_filter.access_reject: --> user1 (3) attr_filter.access_reject: Matched entry DEFAULT at line 11 (3) [attr_filter.access_reject] = updated (3) [eap] = noop (3) policy remove_reply_message_if_eap { (3) if (&reply:EAP-Message && &reply:Reply-Message) { (3) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE (3) else { (3) [noop] = noop (3) } # else = noop (3) } # policy remove_reply_message_if_eap = noop (3) } # Post-Auth-Type REJECT = updated (3) Login incorrect: [user1/password1] (from client localhost port 0) (3) Delaying response for 1.000000 seconds Waking up in 0.2 seconds. Waking up in 0.7 seconds. (3) Sending delayed response (3) Sent Access-Reject Id 53 from 127.0.0.1:1812 to 127.0.0.1:42150 length 20 Waking up in 3.9 seconds. (3) Cleaning up request packet ID 53 with timestamp +189 Ready to process requests Please let me know where did I go wrong. On Wed, Dec 19, 2018 at 9:58 PM Alan DeKok <aland@deployingradius.com> wrote:
On Dec 18, 2018, at 11:01 PM, Daniel Kong <daniel.kongyh@gmail.com> wrote:
Thanks for the feedback, Alan. I have more questions to ask regarding the REST authentication. How does the freeRadius know that when to let the
user
to gain access to the resources after invoke REST authentication?
The server doesn't "let the user gain access to resources". The server *authenticates* the user. By sending an Access-Accept with various attributes in it.
It's important to understand how it works. If you have misconceptions about how the server works, then you won't be asking the right questions, and you won't be doing the right things.
Does it rely on the REST response http status? Eg. if the 3rd party application returns a http status 200 means that the user is authenticated and able to use the resource. However if the REST response returns a http status 401 means that he/she is unauthorized. Does the freeRadius interpret it this way?
Go read raddb/mods-available/rest. This *is* documented.
The configuration file tells you how the http status return codes map to the FreeRADIUS codes that are used to process packets.
Then... read the FreeRADIUS documentation to see how it works. I suggest starting here:
https://networkradius.com/freeradius-documentation/
Read the "technical guide" to get a good overview of how the server works.
In order to use REST authentication only while the others like post-auth, authorize, and accounting using the sql, I only need to configure the REST for authentication. So my configuration would look like this? I just comment off post-auth, authorize, and accounting. Correct me if I am wrong.
You can read the documentation to see how the rest module works. Your questions are answered there.
So after authenticate is successful, freeRadius will do insertion of record to radpostauth and radacct table by itself?
No. This isn't magic.
The sql module puts data into radpostauth and radacct... if you configure the server to use the SQL module in "post-auth" and "accounting".
The default configuration files go through this in great detail.
Our current usage of freeRadius is with mySQL. So we will insert record to radcheck and radreply table while the rest of the table will be handled by freeRadius.
I have no idea what that means.
Now if we are using the REST for authentication, do we still need to insert record to radcheck and radreply? Do we still rely on the 'Auth-Type' in the radcheck table?
The radcheck and radreply tables are used by the SQL module. If you're not using the SQL module, then those tables aren't used.
Your questions seem to be coming from a mindset that the server is magic, and magically "knows" how to do things. It isn't. It has a lot going on, and a lot of configuration files. But in the end it's just a whole bunch of simple things put together in gradually more complex ways.
If you want to use radcheck / radreply, configure the SQL module. And be sure that the SQL module is listed in the virtual server. See sites-available/default for many, many, examples.
Go read the technical guide I think many of your misconceptions are addressed there.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Dec 27, 2018, at 4:48 AM, Daniel Kong <daniel.kongyh@gmail.com> wrote:
Hi, thanks for the guidance. However, I encounter a problem in the rest basic http authentication even though I have provided in the configuration file. ... And here is my radius output ... rlm_rest (rest): Connecting to "http://10.18.6.22:8081/apps" rlm_rest (rest): Reserved connection (8) (3) rest: Expanding URI components (3) rest: EXPAND http://10.18.6.22:8081 (3) rest: --> http://10.18.6.22:8081 (3) rest: EXPAND /apps/user/%{User-Name}/%{User-Password} (3) rest: --> /apps/user/user1/password1 (3) rest: Sending HTTP GET to " http://10.18.6.22:8081/apps/user/user1/password1" (3) rest: Processing response header (3) rest: Status : 401 (Unauthorized)
That seems to be clear.
(3) rest: Type : json (application/json) (3) rest: Parsing attribute "result" (3) rest: WARNING: Failed parsing attribute: Invalid vendor name in attribute name "result", skipping... (3) rest: Parsing attribute "message" (3) rest: WARNING: Failed parsing attribute: Invalid vendor name in attribute name "message", skipping...
The response is json, but not what the REST module expects.
Please let me know where did I go wrong.
The debug log is pretty clear. The user is unauthorized. And, the response isn't what the module expects. The module documentation explains *very* clearly what it sends to the REST API, and what it expects back from the REST API. Alan DeKok.
On Dec 18, 2018, at 11:01 PM, Daniel Kong <daniel.kongyh@gmail.com> wrote:
Thanks for the feedback, Alan. I have more questions to ask regarding the REST authentication. How does the freeRadius know that when to let the
user
to gain access to the resources after invoke REST authentication?
The server doesn't "let the user gain access to resources". The server *authenticates* the user. By sending an Access-Accept with various attributes in it.
It's important to understand how it works. If you have misconceptions about how the server works, then you won't be asking the right questions, and you won't be doing the right things.
Does it rely on the REST response http status? Eg. if the 3rd party application returns a http status 200 means that the user is authenticated and able to use the resource. However if the REST response returns a http status 401 means that he/she is unauthorized. Does the freeRadius interpret it this way?
Go read raddb/mods-available/rest. This *is* documented.
The configuration file tells you how the http status return codes map to the FreeRADIUS codes that are used to process packets.
Then... read the FreeRADIUS documentation to see how it works. I suggest starting here:
https://networkradius.com/freeradius-documentation/
Read the "technical guide" to get a good overview of how the server works.
In order to use REST authentication only while the others like post-auth, authorize, and accounting using the sql, I only need to configure the REST for authentication. So my configuration would look like this? I just comment off post-auth, authorize, and accounting. Correct me if I am wrong.
You can read the documentation to see how the rest module works. Your questions are answered there.
So after authenticate is successful, freeRadius will do insertion of record to radpostauth and radacct table by itself?
No. This isn't magic.
The sql module puts data into radpostauth and radacct... if you configure the server to use the SQL module in "post-auth" and "accounting".
The default configuration files go through this in great detail.
Our current usage of freeRadius is with mySQL. So we will insert record to radcheck and radreply table while the rest of the table will be handled by freeRadius.
I have no idea what that means.
Now if we are using the REST for authentication, do we still need to insert record to radcheck and radreply? Do we still rely on the 'Auth-Type' in the radcheck table?
The radcheck and radreply tables are used by the SQL module. If you're not using the SQL module, then those tables aren't used.
Your questions seem to be coming from a mindset that the server is magic, and magically "knows" how to do things. It isn't. It has a lot going on, and a lot of configuration files. But in the end it's just a whole bunch of simple things put together in gradually more complex ways.
If you want to use radcheck / radreply, configure the SQL module. And be sure that the SQL module is listed in the virtual server. See sites-available/default for many, many, examples.
Go read the technical guide I think many of your misconceptions are addressed there.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
How about 12:20 @ BFCU? Jeremy -----Original Message----- From: Freeradius-Users [mailto:freeradius-users-bounces+jmartin=emcc.edu@lists.freeradius.org] On Behalf Of Daniel Kong Sent: Thursday, December 27, 2018 4:48 AM To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: RESTful API Hi, thanks for the guidance. However, I encounter a problem in the rest basic http authentication even though I have provided in the configuration file. connect_uri = "http://10.18.6.22:8081/apps" authenticate { uri = "${..connect_uri}/user/%{User-Name}/%{User-Password}" method = "get" force_to = "json" require_auth = yes auth = "basic" username = "test" password = "password123" tls = ${..tls} } I have added the following lines to the default configuration file. authorize { if (&User-Password) { update control { Auth-Type := 'rest' } } } authenticate { rest } And here is my radius output (3) Received Access-Request Id 53 from 127.0.0.1:42150 to 127.0.0.1:1812 length 47 (3) User-Name = "user1" (3) User-Password = "password1" (3) # Executing section authorize from file /usr/local/etc/raddb/sites-enabled/default (3) authorize { (3) policy filter_username { (3) if (&User-Name) { (3) if (&User-Name) -> TRUE (3) if (&User-Name) { (3) if (&User-Name =~ / /) { (3) if (&User-Name =~ / /) -> FALSE (3) if (&User-Name =~ /@[^@]*@/ ) { (3) if (&User-Name =~ /@[^@]*@/ ) -> FALSE (3) if (&User-Name =~ /\.\./ ) { (3) if (&User-Name =~ /\.\./ ) -> FALSE (3) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/)) { (3) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/)) -> FALSE (3) if (&User-Name =~ /\.$/) { (3) if (&User-Name =~ /\.$/) -> FALSE (3) if (&User-Name =~ /@\./) { (3) if (&User-Name =~ /@\./) -> FALSE (3) } # if (&User-Name) = notfound (3) } # policy filter_username = notfound (3) [preprocess] = ok (3) [chap] = noop (3) [mschap] = noop (3) [digest] = noop (3) suffix: Checking for suffix after "@" (3) suffix: No '@' in User-Name = "user1", looking up realm NULL (3) suffix: No such realm "NULL" (3) [suffix] = noop (3) eap: No EAP-Message, not doing EAP (3) [eap] = noop (3) [files] = noop (3) [expiration] = noop (3) [logintime] = noop (3) if (&User-Password) { (3) if (&User-Password) -> TRUE (3) if (&User-Password) { (3) update control { (3) Auth-Type := rest (3) } # update control = noop (3) } # if (&User-Password) = noop (3) } # authorize = ok (3) Found Auth-Type = rest (3) # Executing group from file /usr/local/etc/raddb/sites-enabled/default (3) authenticate { rlm_rest (rest): Closing connection (6): Hit idle_timeout, was idle for 134 seconds rlm_rest (rest): You probably need to lower "min" rlm_rest (rest): Closing connection (1): Hit idle_timeout, was idle for 111 seconds rlm_rest (rest): You probably need to lower "min" rlm_rest (rest): Closing connection (7): Hit idle_timeout, was idle for 111 seconds rlm_rest (rest): You probably need to lower "min" rlm_rest (rest): 0 of 0 connections in use. You may need to increase "spare" rlm_rest (rest): Opening additional connection (8), 1 of 32 pending slots used rlm_rest (rest): Connecting to "http://10.18.6.22:8081/apps" rlm_rest (rest): Reserved connection (8) (3) rest: Expanding URI components (3) rest: EXPAND http://10.18.6.22:8081 (3) rest: --> http://10.18.6.22:8081 (3) rest: EXPAND /apps/user/%{User-Name}/%{User-Password} (3) rest: --> /apps/user/user1/password1 (3) rest: Sending HTTP GET to " http://10.18.6.22:8081/apps/user/user1/password1" (3) rest: Processing response header (3) rest: Status : 401 (Unauthorized) (3) rest: Type : json (application/json) (3) rest: Parsing attribute "result" (3) rest: WARNING: Failed parsing attribute: Invalid vendor name in attribute name "result", skipping... (3) rest: Parsing attribute "message" (3) rest: WARNING: Failed parsing attribute: Invalid vendor name in attribute name "message", skipping... rlm_rest (rest): Released connection (8) Need 2 more connections to reach min connections (3) rlm_rest (rest): Opening additional connection (9), 1 of 31 pending slots used rlm_rest (rest): Connecting to "http://10.18.6.22:8081/apps" (3) [rest] = reject (3) } # authenticate = reject (3) Failed to authenticate the user (3) Using Post-Auth-Type Reject (3) # Executing group from file /usr/local/etc/raddb/sites-enabled/default (3) Post-Auth-Type REJECT { (3) attr_filter.access_reject: EXPAND %{User-Name} (3) attr_filter.access_reject: --> user1 (3) attr_filter.access_reject: Matched entry DEFAULT at line 11 (3) [attr_filter.access_reject] = updated (3) [eap] = noop (3) policy remove_reply_message_if_eap { (3) if (&reply:EAP-Message && &reply:Reply-Message) { (3) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE (3) else { (3) [noop] = noop (3) } # else = noop (3) } # policy remove_reply_message_if_eap = noop (3) } # Post-Auth-Type REJECT = updated (3) Login incorrect: [user1/password1] (from client localhost port 0) (3) Delaying response for 1.000000 seconds Waking up in 0.2 seconds. Waking up in 0.7 seconds. (3) Sending delayed response (3) Sent Access-Reject Id 53 from 127.0.0.1:1812 to 127.0.0.1:42150 length 20 Waking up in 3.9 seconds. (3) Cleaning up request packet ID 53 with timestamp +189 Ready to process requests Please let me know where did I go wrong. On Wed, Dec 19, 2018 at 9:58 PM Alan DeKok <aland@deployingradius.com> wrote: - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi Alan,
I get status 401 (unauthorized) is because the site is protected. By
disabling the rest security on the 3rd party application, it can
successfully send the request and get the response, which I have posted
previously by including the username and password for http basic
authentication.
connect_uri = "http://10.18.6.22:8081/apps"
authenticate {
uri = "${..connect_uri}/user/%{User-Name}/%{User-Password}"
method = "get"
force_to = "json"
* require_auth = yes*
* auth = "basic"*
* username = "test"*
* password = "password123"*
tls = ${..tls}
}
Since by specifying those required attributes is not working, so I have
tried to include REST-HTTP-Header, but it doesn't work as well.
connect_uri = "http://10.18.6.22:8081/apps"
authenticate {
uri = "${..connect_uri}/user/%{User-Name}/%{User-Password}"
method = "get"
force_to = "json"
* REST-HTTP-Header = "Authorization: Basic aW5ldHVzZXI6cGFzc3dvcmQxYXBw"*
tls = ${..tls}
}
I am also getting a 401 while trying to send the request. Where is the
problem?
I have tried very hard to understand the return json format from the API
itself, but the information provided is insufficient. I understand it has a
pair of value which consist of attribute and value. That's why in my above
tryout which I tried to put a "result" and "message" attribute. But radius
doesn't recognize this two vendor attribute.
So my question is what is actually needed to pass back to radius? Is it by
specifying 200 (OK) and 401 (Unauthorized) is sufficient for radius to
process?
On Fri, Dec 28, 2018 at 2:52 AM Martin, Jeremy <jmartin@emcc.edu> wrote:
> How about 12:20 @ BFCU?
>
> Jeremy
>
> -----Original Message-----
> From: Freeradius-Users [mailto:freeradius-users-bounces+jmartin=
> emcc.edu@lists.freeradius.org] On Behalf Of Daniel Kong
> Sent: Thursday, December 27, 2018 4:48 AM
> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org>
> Subject: Re: RESTful API
>
> Hi, thanks for the guidance. However, I encounter a problem in the rest
> basic http authentication even though I have provided in the configuration
> file.
>
> connect_uri = "http://10.18.6.22:8081/apps"
> authenticate {
> uri = "${..connect_uri}/user/%{User-Name}/%{User-Password}"
> method = "get"
> force_to = "json"
> require_auth = yes
> auth = "basic"
> username = "test"
> password = "password123"
> tls = ${..tls}
> }
>
> I have added the following lines to the default configuration file.
>
> authorize {
> if (&User-Password) {
> update control {
> Auth-Type := 'rest'
> }
> }
> }
>
> authenticate {
> rest
> }
>
> And here is my radius output
>
> (3) Received Access-Request Id 53 from 127.0.0.1:42150 to 127.0.0.1:1812
> length 47
> (3) User-Name = "user1"
> (3) User-Password = "password1"
> (3) # Executing section authorize from file
> /usr/local/etc/raddb/sites-enabled/default
> (3) authorize {
> (3) policy filter_username {
> (3) if (&User-Name) {
> (3) if (&User-Name) -> TRUE
> (3) if (&User-Name) {
> (3) if (&User-Name =~ / /) {
> (3) if (&User-Name =~ / /) -> FALSE
> (3) if (&User-Name =~ /@[^@]*@/ ) {
> (3) if (&User-Name =~ /@[^@]*@/ ) -> FALSE
> (3) if (&User-Name =~ /\.\./ ) {
> (3) if (&User-Name =~ /\.\./ ) -> FALSE
> (3) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/)) {
> (3) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/)) ->
> FALSE
> (3) if (&User-Name =~ /\.$/) {
> (3) if (&User-Name =~ /\.$/) -> FALSE
> (3) if (&User-Name =~ /@\./) {
> (3) if (&User-Name =~ /@\./) -> FALSE
> (3) } # if (&User-Name) = notfound
> (3) } # policy filter_username = notfound
> (3) [preprocess] = ok
> (3) [chap] = noop
> (3) [mschap] = noop
> (3) [digest] = noop
> (3) suffix: Checking for suffix after "@"
> (3) suffix: No '@' in User-Name = "user1", looking up realm NULL
> (3) suffix: No such realm "NULL"
> (3) [suffix] = noop
> (3) eap: No EAP-Message, not doing EAP
> (3) [eap] = noop
> (3) [files] = noop
> (3) [expiration] = noop
> (3) [logintime] = noop
> (3) if (&User-Password) {
> (3) if (&User-Password) -> TRUE
> (3) if (&User-Password) {
> (3) update control {
> (3) Auth-Type := rest
> (3) } # update control = noop
> (3) } # if (&User-Password) = noop
> (3) } # authorize = ok
> (3) Found Auth-Type = rest
> (3) # Executing group from file /usr/local/etc/raddb/sites-enabled/default
> (3) authenticate {
> rlm_rest (rest): Closing connection (6): Hit idle_timeout, was idle for
> 134 seconds rlm_rest (rest): You probably need to lower "min"
> rlm_rest (rest): Closing connection (1): Hit idle_timeout, was idle for
> 111 seconds rlm_rest (rest): You probably need to lower "min"
> rlm_rest (rest): Closing connection (7): Hit idle_timeout, was idle for
> 111 seconds rlm_rest (rest): You probably need to lower "min"
> rlm_rest (rest): 0 of 0 connections in use. You may need to increase
> "spare"
> rlm_rest (rest): Opening additional connection (8), 1 of 32 pending slots
> used rlm_rest (rest): Connecting to "http://10.18.6.22:8081/apps"
> rlm_rest (rest): Reserved connection (8)
> (3) rest: Expanding URI components
> (3) rest: EXPAND http://10.18.6.22:8081
> (3) rest: --> http://10.18.6.22:8081
> (3) rest: EXPAND /apps/user/%{User-Name}/%{User-Password}
> (3) rest: --> /apps/user/user1/password1
> (3) rest: Sending HTTP GET to "
> http://10.18.6.22:8081/apps/user/user1/password1"
> (3) rest: Processing response header
> (3) rest: Status : 401 (Unauthorized)
> (3) rest: Type : json (application/json)
> (3) rest: Parsing attribute "result"
> (3) rest: WARNING: Failed parsing attribute: Invalid vendor name in
> attribute name "result", skipping...
> (3) rest: Parsing attribute "message"
> (3) rest: WARNING: Failed parsing attribute: Invalid vendor name in
> attribute name "message", skipping...
> rlm_rest (rest): Released connection (8) Need 2 more connections to reach
> min connections (3) rlm_rest (rest): Opening additional connection (9), 1
> of 31 pending slots used rlm_rest (rest): Connecting to "
> http://10.18.6.22:8081/apps"
> (3) [rest] = reject
> (3) } # authenticate = reject
> (3) Failed to authenticate the user
> (3) Using Post-Auth-Type Reject
> (3) # Executing group from file /usr/local/etc/raddb/sites-enabled/default
> (3) Post-Auth-Type REJECT {
> (3) attr_filter.access_reject: EXPAND %{User-Name}
> (3) attr_filter.access_reject: --> user1
> (3) attr_filter.access_reject: Matched entry DEFAULT at line 11
> (3) [attr_filter.access_reject] = updated
> (3) [eap] = noop
> (3) policy remove_reply_message_if_eap {
> (3) if (&reply:EAP-Message && &reply:Reply-Message) {
> (3) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE
> (3) else {
> (3) [noop] = noop
> (3) } # else = noop
> (3) } # policy remove_reply_message_if_eap = noop
> (3) } # Post-Auth-Type REJECT = updated
> (3) Login incorrect: [user1/password1] (from client localhost port 0)
> (3) Delaying response for 1.000000 seconds Waking up in 0.2 seconds.
> Waking up in 0.7 seconds.
> (3) Sending delayed response
> (3) Sent Access-Reject Id 53 from 127.0.0.1:1812 to 127.0.0.1:42150 length
> 20
> Waking up in 3.9 seconds.
> (3) Cleaning up request packet ID 53 with timestamp +189 Ready to process
> requests
>
> Please let me know where did I go wrong.
>
> On Wed, Dec 19, 2018 at 9:58 PM Alan DeKok <aland@deployingradius.com>
> wrote:
>
> > On Dec 18, 2018, at 11:01 PM, Daniel Kong <daniel.kongyh@gmail.com>
> wrote:
> > >
> > > Thanks for the feedback, Alan. I have more questions to ask
> > > regarding the REST authentication. How does the freeRadius know that
> > > when to let the
> > user
> > > to gain access to the resources after invoke REST authentication?
> >
> > The server doesn't "let the user gain access to resources". The
> > server
> > *authenticates* the user. By sending an Access-Accept with various
> > attributes in it.
> >
> > It's important to understand how it works. If you have
> > misconceptions about how the server works, then you won't be asking
> > the right questions, and you won't be doing the right things.
> >
> > > Does it
> > > rely on the REST response http status? Eg. if the 3rd party
> > > application returns a http status 200 means that the user is
> > > authenticated and able
> > to
> > > use the resource. However if the REST response returns a http status
> > > 401 means that he/she is unauthorized. Does the freeRadius interpret
> > > it this way?
> >
> > Go read raddb/mods-available/rest. This *is* documented.
> >
> > The configuration file tells you how the http status return codes
> > map to the FreeRADIUS codes that are used to process packets.
> >
> > Then... read the FreeRADIUS documentation to see how it works. I
> > suggest starting here:
> >
> > https://networkradius.com/freeradius-documentation/
> >
> > Read the "technical guide" to get a good overview of how the server
> > works.
> >
> > > In order to use REST authentication only while the others like
> > > post-auth, authorize, and accounting using the sql, I only need to
> > > configure the
> > REST
> > > for authentication. So my configuration would look like this? I just
> > > comment off post-auth, authorize, and accounting. Correct me if I am
> > wrong.
> >
> > You can read the documentation to see how the rest module works.
> > Your questions are answered there.
> >
> > > So after authenticate is successful, freeRadius will do insertion of
> > record
> > > to radpostauth and radacct table by itself?
> >
> > No. This isn't magic.
> >
> > The sql module puts data into radpostauth and radacct... if you
> > configure the server to use the SQL module in "post-auth" and
> "accounting".
> >
> > The default configuration files go through this in great detail.
> >
> > > Our current usage of freeRadius is with mySQL. So we will insert
> > > record
> > to
> > > radcheck and radreply table while the rest of the table will be
> > > handled
> > by
> > > freeRadius.
> >
> > I have no idea what that means.
> >
> > > Now if we are using the REST for authentication, do we still need to
> > > insert record to radcheck and radreply? Do we still rely on the
> > > 'Auth-Type' in the radcheck table?
> >
> > The radcheck and radreply tables are used by the SQL module. If
> > you're not using the SQL module, then those tables aren't used.
> >
> > Your questions seem to be coming from a mindset that the server is
> > magic, and magically "knows" how to do things. It isn't. It has a
> > lot going on, and a lot of configuration files. But in the end it's
> > just a whole bunch of simple things put together in gradually more
> complex ways.
> >
> > If you want to use radcheck / radreply, configure the SQL module.
> > And be sure that the SQL module is listed in the virtual server. See
> > sites-available/default for many, many, examples.
> >
> > Go read the technical guide I think many of your misconceptions are
> > addressed there.
> >
> > Alan DeKok.
> >
> >
> > -
> > List info/subscribe/unsubscribe? See
> > http://www.freeradius.org/list/users.html
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
On 02-01-19 10:39, Daniel Kong wrote:
Hi Alan,
I get status 401 (unauthorized) is because the site is protected. By disabling the rest security on the 3rd party application, it can successfully send the request and get the response, which I have posted previously by including the username and password for http basic authentication.
connect_uri = "http://10.18.6.22:8081/apps" authenticate { uri = "${..connect_uri}/user/%{User-Name}/%{User-Password}" method = "get" force_to = "json" * require_auth = yes* * auth = "basic"* * username = "test"* * password = "password123"* tls = ${..tls} }
Since by specifying those required attributes is not working, so I have tried to include REST-HTTP-Header, but it doesn't work as well.
connect_uri = "http://10.18.6.22:8081/apps" authenticate { uri = "${..connect_uri}/user/%{User-Name}/%{User-Password}" method = "get" force_to = "json" * REST-HTTP-Header = "Authorization: Basic aW5ldHVzZXI6cGFzc3dvcmQxYXBw"* tls = ${..tls} }
I am also getting a 401 while trying to send the request. Where is the problem?
Since the connection is made via HTTP without TLS: have you tried tcpdump/wireshark to inspect the HTTP headers? If the Authz header is added and the request is rejected by the webserver, the problem is probably in the web server, not the RADIUS server. -- Herwin Weststrate
On Jan 2, 2019, at 4:39 AM, Daniel Kong <daniel.kongyh@gmail.com> wrote: ... Please edit your replies. There's no need to include 100's of lines of the previous message at the bottom of your post. We've seen it already, and we don't need to see it again.
I get status 401 (unauthorized) is because the site is protected. By disabling the rest security on the 3rd party application, it can successfully send the request and get the response, which I have posted previously by including the username and password for http basic authentication.
OK... I'm not sure why you're "protecting" a REST API from FreeRADIUS. But whatever...
connect_uri = "http://10.18.6.22:8081/apps" authenticate { uri = "${..connect_uri}/user/%{User-Name}/%{User-Password}" method = "get" force_to = "json" * require_auth = yes* * auth = "basic"* * username = "test"* * password = "password123"* tls = ${..tls} }
Since by specifying those required attributes is not working,
What does that mean? You should be able to look at either the FreeRADIUS logs, or the REST server logs to see what's going on.
so I have tried to include REST-HTTP-Header, but it doesn't work as well.
connect_uri = "http://10.18.6.22:8081/apps" authenticate { uri = "${..connect_uri}/user/%{User-Name}/%{User-Password}" method = "get" force_to = "json" * REST-HTTP-Header = "Authorization: Basic aW5ldHVzZXI6cGFzc3dvcmQxYXBw"* tls = ${..tls} }
I am also getting a 401 while trying to send the request. Where is the problem?
Without detailed information (i.e. logs), there's no way to tell. You have to figure out what's going on. You can't just change the configuration and hope it will now magically work.
I have tried very hard to understand the return json format from the API itself, but the information provided is insufficient. I understand it has a pair of value which consist of attribute and value. That's why in my above tryout which I tried to put a "result" and "message" attribute. But radius doesn't recognize this two vendor attribute.
You need to have the API return json, in the format described in mods-available/rest. Something like this should work: "User-Name": { "op":"=", "value":"bob" }
So my question is what is actually needed to pass back to radius? Is it by specifying 200 (OK) and 401 (Unauthorized) is sufficient for radius to process?
The REST module documentation describes what HTTP codes the REST server should return. I've already said this. Please read the documentation. Alan DeKok.
participants (5)
-
Alan DeKok -
Daniel Kong -
Herwin Weststrate -
jm+freeradiususer＠roth.lu -
Martin, Jeremy