Authentication Schemes through REST interface

Other Northbound Interfaces
1

What authentication schemes are available using the northbound REST interface out of the box?
Is it only Basic Auth?
If so, does authentication happen on every request sent through the REST interface at the ConfD layer?

Is there any way to reuse connections when using tail-f REST interface?

2

ConfD only support basic authentication and yes, authentication happens on every request.

There is a way to reuse connections and it is on by default, see this small example sending two requests using curl:

$ curl -v --basic -u admin:admin http://localhost:8008/api?verbose http://localhost:8008/api/running\?shallow
* Hostname was NOT found in DNS cache
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8008 (#0)
* Server auth using Basic with user 'admin'
> GET /api?verbose HTTP/1.1
> Authorization: Basic YWRtaW46YWRtaW4=
> User-Agent: curl/7.35.0
> Host: localhost:8008
> Accept: */*
>
< HTTP/1.1 200 OK
* Server  is not blacklisted
< Server:
< Date: Wed, 16 Sep 2015 17:16:10 GMT
< Cache-Control: private, no-cache, must-revalidate, proxy-revalidate
< Content-Length: 288
< Content-Type: application/vnd.yang.api+xml
< Vary: Accept-Encoding
< Pragma: no-cache
<
<api xmlns="http://tail-f.com/ns/rest" xmlns:y="http://tail-f.com/ns/rest" y:self="/api">
  <version>0.5</version>
  <config y:self="/api/config"/>
  <running y:self="/api/running"/>
  <operational y:self="/api/operational"/>
  <operations/>
  <rollbacks y:self="/api/rollbacks"/>
</api>
* Connection #0 to host localhost left intact
* Found bundle for host localhost: 0x128e970
* Re-using existing connection! (#0) with host localhost
* Connected to localhost (127.0.0.1) port 8008 (#0)
* Server auth using Basic with user 'admin'
> GET /api/running?shallow HTTP/1.1
> Authorization: Basic YWRtaW46YWRtaW4=
> User-Agent: curl/7.35.0
> Host: localhost:8008
> Accept: */*
>
< HTTP/1.1 200 OK
* Server  is not blacklisted
< Server:
< Date: Wed, 16 Sep 2015 17:16:10 GMT
< Last-Modified: Fri, 01 Jan 1971 06:00:00 GMT
< Cache-Control: private, no-cache, must-revalidate, proxy-revalidate
< Etag: 1442-417684-559877
< Content-Type: application/vnd.yang.datastore+xml
< Transfer-Encoding: chunked
< Pragma: no-cache
<
<data xmlns:y="http://tail-f.com/ns/rest">
  <dhcp xmlns="http://yang-central.org/ns/example/dhcp"/>
  <nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm"/>
  <aaa xmlns="http://tail-f.com/ns/aaa/1.1"/>
  <operations>
    <lock>/api/running/_lock</lock>
    <rollback>/api/running/_rollback</rollback>
  </operations>
</data>
* Connection #0 to host localhost left intact

In the output from the second request we have the lines:

* Found bundle for host localhost: 0x128e970
* Re-using existing connection! (#0) with host localhost

indicating that the the connection is reused for the second request.

3

I am trying to understand if reusing the HTTP connection can also save time on authentication or does it only help with reducing the TCP handshake time for every request?

If the connection is reused, what is the need to send the “Authorization” header? Shouldn’t the server just authenticate it based on the connection - either automatically or with a Cookie that can be set for further requests?

4

Also, since the headers on the response do not contain any “Keep-Alives”, I am inclined to believe that persistent HTTP connections are not supported correctly.

I should probably run Wireshark to confirm this.

5

You’re correct, it only helps with reducing the time for setting up and tearing down the connection. However, there’re no extra packets, only a few extra bytes in the HTTP-header.

I’m not an expert on REST APIs but it is my understanding that a RESTful interface should be stateless and allow clients to perform any needed task in one request; because the full state needed to do that is held by the client, not the server and a cookie provided by the sever is not truly stateless.

6

Hi Jonas,
This topic is about a year old. But I am wondering if, since that time, there has been any talk about plans to support anything other than basic authentication in the REST API? For example, generating a keypair. This would be used by another program (on the same box) accessing the REST API, not by a client with user credentials.
Thank you.

7

Hi Jude,
Sorry, no. ConfD still only support basic authentication.