Developing an API in the healthcare field to monetize that functionality that will delight your end users, is a sure bet of success. But you don’t want anyone to use it without proper authorization: you must protect it.
Enabling the endpoint access mechanisms of your API is one of the fundamental aspects to consider in the design phase and one of the most costly in resources and time. Nubentos provides the ideal interface to save you this job, but still, it is necessary to apply some security measures on your side.
In this series of articles we will show you different mechanisms to secure the endpoint of your API for Health and how you should make the configuration in the Nubentos platform to connect to it.
- We will start with the most basic mechanism, hiding the endpoint from the world. Simple, fast, but still too exposed.
- We will continue to incorporate an additional basic mechanism: a username and password to make requests to the endpoint with authorization.
- Finally, we will see an even more refined solution that will help you solve the shortcomings of the previous solutions.
Are you ready? Let us begin.
Tabla de Contenidos
Hide the endpoint to the world
We start from the following architecture, where the API provider (you) has an application server that handles requests. It also has a load balancer or reverse proxy, which will be responsible for routing requests according to the requested context.
In this way, when requesting http://endpoint/api the request will reach the application server that will be responsible for responding. If another context is requested, for example http://endpoint/doc, it will direct the request to some static content.
The REST API you have developed can be exposed using an URL. A first step to hide the existence of your API is to give the domain a cryptic name and carefully manage who we provide this URL.
We could generate a domain name like: d635865a-dab5-4254-804f-7f65eb99aca2.apiprovider.com
You can use the uuidgen command to generate a random string. You just have to make sure that the first character is a letter to comply with RFC 1035.
This method is not a good practice, because sooner or later someone will be able to identify the URL, either by the configuration used by the clients that access the API or by listening to the traffic generated on the network.
How do we perform this configuration?
For this example, the load balancer functions will be in charge of an instance of nginx (although we could also use Apache WebServer 2.4).
We assume that you have the IP address of your application server where you are serving a REST API (for example 192.168.0.10), which allows us to consult a list of doctors by their identifier.
Using the resource “/ doctor” and passing it the identifier “/ 1”, the result will be a response in json format with the main fields of the doctor entity.
We will start from a nginx installation that is working correctly on the server as a load balancer. Instructions on how to install nginx in the most common distributions can be found at this link http://docs.nginx.com. For this example we will use the installation on Red Hat Linux.
In essence, all you need to do is configure nginx with instructions on what type of connections to listen to and where to redirect them.
To do this, we create a new configuration file using the text editor of your choice, for example with nano:
In the load-balancer.conf file, define two sections, upstream and server, as in the examples that follow.
upstream applicationserver {
server 192.168.0.10:8080;
}
server {
listen 80;
server_name d635865a-dab5-4254-804f-7f65eb99aca2.apiprovider.com;
proxy_set_header Host $ http_host;
location / api {
proxy_pass http: // applicationserver;
}
}
Where upstream refers to the IP address and port where the application server is listening. And server defines the port where the nginx server rises and the host to which it is associated.
After reloading the nginx configuration, it will only respond to requests that use the URL http://d635865a-dab5-4254-804f-7f65eb99aca2.apiprovider.com/api/.
You will only have to register a type “A” record in your dns provider by associating the domain with the IP where the nginx server is running.
You can validate that it has propagated correctly by consulting your server’s dns:
Server: 8.8.8.8
Address: 8.8.8.8 # 53
Non-authoritative answer:
Name: d635865a-dab5 -4254-804f-7f65eb99aca2.apiprovider.com
Address: 35.205.205.205
As we have mentioned, we only need to know the URL to invoke the API. As a test, we will use the curl command requesting the “doctor” data with identifier “1”.
* Connected to d635865a-dab5-4254-804f-7f65eb99aca2.apiprovider.com (:: 1) port 80 (# 0)
> GET / api / doctor / 1 HTTP / 1.1
> Host: d635865a-dab5-4254-804f-7f65eb99aca2.apiprovider.com
> User-Agent: curl / 7.54.0
> Accept: * / *
>
<HTTP / 1.1 200 OK
<Server: nginx / 1.10.1
<Date: Sun, 18 Aug 2019 07:09:39 GMT
<Content-Type: application / json
<Content-Length: 332
<Connection: keep-alive
<Sl -Request-Valid: true
{
“category”: {
“id”: 45011383,
“name”: “enim ex laboris”
},
“id”: 1,
“name”: “doggie”,
“photoUrls”: [
“esse pariatur sit “,
” aute ad in “,
” voluptate velit “,
” officia proident sed ipsum “
],
” status “:” vacations “,
” tags “: [
{
” id “: 9940033,
” name “:” ut “
},
{
“id”: 35005282,
“name”: “non dolore dolore irure nostrud”
},
{
“id”: 5593403,
“name”: “ut nulla ipsum”
}
]
}
As you can see the data provided are completely fictional.
How do we register this type of endpoint on the Nubentos platform?
It is as simple as accessing the publishing portal with your development user, and in the Design step of creating your API, fill in the endpoint field with the URL for the corresponding environment.
As we mentioned earlier, this method offers few security guarantees, and is not the one we recommend.
In the next issue of ths mini series, we will go one step further in the right direction towards securing the endpoint of your API for Health.
Access the following parts:
0 Comments