RESTful API

[Daniel Kong]

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 at deployingradius.com>
wrote:

> On Dec 18, 2018, at 11:01 PM, Daniel Kong <daniel.kongyh at 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