RESTful API
Daniel Kong
daniel.kongyh at gmail.com
Wed Jan 2 10:39:06 CET 2019
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 at emcc.edu> wrote:
> How about 12:20 @ BFCU?
>
> Jeremy
>
> -----Original Message-----
> From: Freeradius-Users [mailto:freeradius-users-bounces+jmartin=
> emcc.edu at lists.freeradius.org] On Behalf Of Daniel Kong
> Sent: Thursday, December 27, 2018 4:48 AM
> To: FreeRadius users mailing list <freeradius-users at 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 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
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
More information about the Freeradius-Users
mailing list