A safer mechanism than leaving access to a hidden and secret URL is to put a lock, by using a username and password. In this implementation, when a request is made to the endpoint, the balancing server will indicate that we are not authorized and will ask us to provide a username and password, returning a 401 ‘Unauthorized’ HTTP code to the first request.
The client making the first request will send the username and password encoded in Base64, using the header “Authorization”.
With this mechanism it is no longer necessary to use a cryptic domain name, since you will have your endpoint protected. With this you will gain ease of use and that this can be an entry point for your users.
You can use names that are easier to remember and use, like the following:
http://api.apiprovider.com/api
The main problem with this mechanism lies in the sending of user and password data using an encryption in Base64, since this is reversible. An attacker who intercepts the communication can obtain the username and password, unless the communications channel between the client and the endpoint is encrypted using TLS.
That is why this mechanism is only recommended if the endpoint is published using “https”.
Endpoint with basic authentication and publication via https
Starting from the installation shown above, edit the file load-balancer.conf and replace its content with the following code:
upstream applicationserver {
server 192.168.0.10:8080;
}
server {
listen 443 ssl;
server_name api.apiprovider.com;
ssl_certificate /etc/ssl/certs/api.apiprovider.crt;
ssl_certificate_key /etc/ssl/private/api.apiprovider.key;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:! aNULL:! MD5;
location / api {
proxy_pass http: // applicationserver;
auth_basic “Administrator’s Area”;
#Change double quote when copy and paste.
auth_basic_user_file /etc/nginx/.htpasswd;
}
}
There are two points that we must discuss before reloading the configuration. The first is to generate the file where users and passwords will be stored, and the second is to provide the certificates that we will use in the https connection.
Let’s start with generating the file with the username / password pairs.
For the rest of the users we will use the same command but without the “-c” option.
The next step is to generate the certificate and sign it.
If we have a certificate from a certifying entity, we will change the name of the private key file (.key) to api.apiprovider.com.key, and the signed digital certificate file (.crt) to api.apiprovider.com.crt. Then, put them in the path / etc / ssl / private and / etc / ssl / certs respectively.
Both files must have restricted permissions so that other users of the system cannot access. In the event that we do not have a signed certificate, we can sign them ourselves generating a self-signed certificate. This link indicates the steps (1).
Once the nginx configuration is reloaded, you can verify that the configuration is working correctly.
To see if the endpoint is being served correctly through https we can use the following command line:
CONNECTED (00000005)
depth = 0 C = ES, ST = ANDALUCIA, L = SEVILLA, O = Nubentos, SL, OU = Operations, CN = api.apiprovider.com
verify error: num = 18: self signed certificate
verify return: 1
depth = 0 C = ES, ST = ANDALUCIA, L = SEVILLA, O = Nubentos, SL, OU = Operations, CN = api.apiprovider.com
verify return: 1
—
Certificate chain
0 s: / C = ES / ST = ANDALUCIA / L = SEVILLA / O = Nubentos, SL / OU = Operations / CN = api.apiprovider.com
i: /C=ES/ST=ANDALUCIA/L=SEVILLA/O=Nubentos,SL/OU=Operaciones/CN=api.apiprovider.com
—– BEGIN CERTIFICATE —- –
MIIDcjCCAloCCQCCFkZS7MYlwTANBgkqhkiG9w0BAQUFADB7MQswCQYDVQQGEwJF
UzESMBAGA1UECAwJQU5EQUxVQ0lBMRAwDgYDVQQHDAdTRVZJTExBMRIwEAYDVQQK
…
Let’s try a request to the endpoint using “curl”:
* Trying :: 1 …
* TCP_NODELAY set
* Connected to api.apiprovider.com (:: 1) port 443 (# 0)
* ALPN, offering h2
* ALPN, offering http / 1.1
* Cipher selection: ALL:! EXPORT:! EXPORT40:! EXPORT56:! ANULL:! LOW:! RC4: @STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
…
* Server certificate:
* subject: C = ES; ST = ANDALUCIA; L = SEVILLA; O = Nubentos, SL; OU = Operations; CN = api.apiprovider.com
* start date: Aug 17 17:59:33 2019 GMT
* expire date: Jun 6 17:59:33 2022 GMT
* issuer: C = ES; ST = ANDALUCIA; L = SEVILLA; O = Nubentos, SL; OU = Operations; CN = api.apiprovider.com
* SSL certificate verify result: self signed certificate (18), continuing anyway.
> GET / api / doctor / 1 HTTP / 1.1
> Host: api.apiprovider.com
> User-Agent: curl / 7.54.0
> Accept: * / *
> Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ =
>
<HTTP / 1.1 400 200 OK
< Server: nginx / 1.10.1
<Date: Sun, 18 Aug 2019 05:27:51 GMT
<Content-Type: application / json
<Content-Length: 432
<Connection: keep-alive
<
* Connection # 0 to host api. apiprovider.com left intact
How to use this type of endpoint in Nubentos?
You must go to the tab “Implement” of your API (by creating it, or by editing your existing API), and indicate the url of the new endpoint.
Just below this field, you can see two additional sections.
The first is to manage the digital certificate used for the endpoint published by https. If the certificate is self-signed, you must add the public part of it to your certificate store, as shown in the following screen.
In the event that you are using a certificate signed by a recognized certification body, this step will not be necessary.
The second section is to show security options, and that is where you can choose the authentication method.
Select the options as they syndicate in the screenshot and enter the credentials.
With this step you can access the endpoint with your username and password through Nubentos.
Access the other parts of this serie
- How to enable access to your endpoint in a secure way – part 1
- How to enable access to your endpoint securely – part 3
0 Comments