+34 688 911 123 hola@nubentos.com

En el anterior artículo de esta serie, ocultamos tu endpoint con la esperanza de que solo un grupo limitado tuviera acceso al mismo, pero dejándolo expuesto y accesible. Veamos a continuación una alternativa más prudente para habilitar el acceso a tu endpoint de forma segura.

Añadir un acceso con usuario y contraseña

Un mecanismo más seguro que dejar abierto el acceso a una URL oculta y secreta es ponerle una cerradura, mediante un usuario y contraseña.

En esta implementación, cuando se realiza una petición al endpoint, el servidor de balanceo nos indicará que no estamos autorizados y nos solicitará que aportemos un usuario y contraseña, devolviendo un código HTTP 401 ‘No Autorizado’ a la primera petición.

El cliente que realiza la primera petición enviará los datos del usuario y contraseña codificadas en Base64, mediante la cabecera “Authorization”.

Con este mecanismo ya no es necesario emplear un nombre de dominio críptico, ya que tendrás protegido tu endpoint. Con ello ganarás en facilidad de uso y en que este pueda ser un punto de entrada para tus usuarios. 

Podrás usar nombres más fáciles de recordar y usar como el siguiente:

http://api.apiprovider.com/api

03_Endpoint_Basic

 

El principal problema de este mecanismo radica en el envío de los datos de usuario y contraseña empleando una codificación en Base64, ya que ésta es reversible.

Un atacante que intercepte la comunicación podrá obtener el usuario y la contraseña, a menos que el canal de comunicaciones entre el cliente y el endpoint esté encriptado usando TLS.

Es por ello que este mecanismo sólo se recomienda si el endpoint se publica mediante “https”.

Endpoint con autenticación básica y publicación mediante https

Partiendo de la instalación del caso anterior, editamos el fichero load-balancer.conf y sustituiremos su contenido por el siguiente código:

http {

   

   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;

  }

}

Hay dos puntos que debemos tratar antes de recargar la configuración. El primero es generar el fichero donde se almacenarán los usuarios y contraseñas, y el segundo es proporcionar los certificados que emplearemos en la conexión https.

Empecemos con generar el fichero con los pares usuario/contraseña.

sudo htpasswd -c /etc/nginx/.htpasswd <username>

Para el resto de usuarios usaremos el mismo comando pero sin la opción “-c” .

El siguiente paso es generar el certificado y firmarlo.

Si disponemos de certificado proveniente de una entidad certificadora, cambiaremos el nombre del fichero de clave privada (.key) por api.apiprovider.com.key, y el fichero del certificado digital firmado (.crt) por api.apiprovider.com.crt y los ubicamos en la ruta /etc/ssl/private y /etc/ssl/certs respectivamente.

A ambos ficheros debemos restringirles los permisos para que otros usuarios del sistema no puedan acceder.

En el caso de que no dispongamos de un certificado firmado podemos firmarlo nosotros mismos generando un certificado autofirmado. En este enlace se indican los pasos (1).

Una vez recargada la configuración del nginx, podrás comprobar que la configuración está funcionando de forma correcta.

Para ver si el endpoint se está sirviendo correctamente mediante https podemos usar la siguiente línea de comandos:

openssl s_client -showcerts -host api.apiprovider.com -port 443

 

CONNECTED(00000005)

depth=0 C = ES, ST = ANDALUCIA, L = SEVILLA, O = Nubentos,SL, OU = Operaciones, 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 = Operaciones, CN = api.apiprovider.com

verify return:1

Certificate chain

 0 s:/C=ES/ST=ANDALUCIA/L=SEVILLA/O=Nubentos,SL/OU=Operaciones/CN=api.apiprovider.com

   i:/C=ES/ST=ANDALUCIA/L=SEVILLA/O=Nubentos,SL/OU=Operaciones/CN=api.apiprovider.com

—–BEGIN CERTIFICATE—–

MIIDcjCCAloCCQCCFkZS7MYlwTANBgkqhkiG9w0BAQUFADB7MQswCQYDVQQGEwJF

UzESMBAGA1UECAwJQU5EQUxVQ0lBMRAwDgYDVQQHDAdTRVZJTExBMRIwEAYDVQQK

 

Vamos a probar una petición al endpoint empleando “curl”: 

curl -k -L -v -H ‘Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=’ -X GET https://api.apiprovider.com/api/doctor/1 

 

*   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=Operaciones; 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=Operaciones; 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

¿Cómo emplear este tipo de endpoint en Nubentos?

Debemos posicionarnos en la pestaña “Implement” de tu API (al crearla, o editando la API existente), e indicamos la url del nuevo endpoint. 

03_Nubentos_Endpoint_Options

 

Justo debajo de este campo, puedes ver dos secciones adicionales. 

La primera es para gestionar el certificado digital que se emplea para el endpoint publicado por https. Si el certificado es autofirmado, debes añadir la parte pública del mismo a tu almacén de certificados, como se muestra en la siguiente pantalla.

03_Nubentos_Endpoint_certificate

 

En el caso de que estés usando un certificado firmado por una entidad certificadora reconocida, este paso no será necesario.

La segunda sección es para mostrar las opciones de seguridad, y es donde puedes elegir el método de autenticación.

03_Nubentos_Endpoint_BasicAuth

 

Selecciona las opciones como se indican en la captura de pantalla e introduce las credenciales.

Con este paso ya podrás acceder al endpoint con tu usuario y contraseña a través de Nubentos.

 

0 comentarios

Enviar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This