Versiones comparadas

Clave

  • Se ha añadido esta línea.
  • Se ha eliminado esta línea.
  • El formato se ha cambiado.

...

UI Expand
titleAlternativas Consideradas

Se analiza el uso de API Keys y de Client Secret como mecanismo de autenticación y autorización para la comunicación entre sistemas del SAS. Esta propuesta se divide en tres alternativas:

Alternativa 1:

Api key para todos los sistemas igual. Guardar el valor en k8s y obtenerlo desde una variable de entorno. Es sólo autenticación, no incluye autorización (es decir, cualquier sistema puede logar cualquier evento)

Alternativa 2:

Incluir una autorización por cada sistema productor. En este caso habría que disponer de una persistencia que almacenara API-KEY, sistema y eventos autorizados a logar. Esta alternativa es más elegante aunque más costosa, y permite un grano más fino de autenticación y autorización. 

Alternativa 3:

Otra alternativa al Ali-key es el uso de Keycloak con Client Id y secret. Este mecanismo permite la autentificación y autorización entre máquinas. 


UI Expand
titleAlternativa 1

Las API Keys permiten autenticar y autorizar a un sistema tercero a acceder al recurso del sistema responsable del mismo. Para ello, cada sistema tercero debe obtener una API Key y una API Secret Key.

UI Expand
titlePosibilidades
  • Autenticación y autorización: Las API Keys permiten autenticar y autorizar a un sistema tercero a acceder al recurso del sistema responsable del mismo.
  • Autorización: Las API Keys permiten autorizar a un sistema tercero a acceder al recurso del sistema responsable.
  • Flexibilidad: Las API Keys pueden ser utilizadas para restringir el acceso a al recurso del sistema  en función de las necesidades de cada sistema tercero.
  • Seguridad: Las API Keys pueden ser utilizadas para proteger el recurso del sistema de accesos no autorizados.
UI Expand
titleVentajas
  • Fácil implementación: Las API Keys son fáciles de implementar y utilizar.
  • Escalabilidad: Las API Keys son escalables y pueden ser utilizadas para gestionar un gran número de sistemas terceros.
  • Coste: Las API Keys son una solución de bajo coste.


UI Expand
titleDesventajas
  • Requiere gestión: Las API Keys requieren una gestión adecuada para evitar que sean utilizadas de forma fraudulenta.
  • No es adecuada para todos los casos: Las API Keys no son adecuadas para casos en los que se requiere una autenticación y autorización más compleja, como la autenticación multifactor.
  • Nivel de seguridad muy básico: La API Key no puede ser revocada fácilmente sin altos costes, dado que es única cualquier sistema que la conozca puede hacer uso de ella para registrar auditoria, y el control es prácticamente inexistente una vez esté entregada al primer proyecto. 
UI Expand
titleCoste Adopción

Dentro de las ventajas por parte de se plantea que este sistema es de bajo coste pero no se está contando con la duplicidad que implica la multiplicidad en los sistemas de autenticación, así pues la evaluación de coste que se hace al respecto es la siguiente:

  • Coste de API Keys
  • Coste Integración con Autentificación Keycloak (la autentificación máquina - máquina no es excluyente con usuario - máquina por lo que el sistema destino debe soportar ambas autentificaciones)
  • Coste por solapamiento. Estaríamos tratando la autentificación con dos sistemas diferentes con lo que tenemos duplicidades que complican la operación. 
  • Coste de operación (Es necesario catalogar y administrar los api-key, esta es una tarea fundamentalmente manual)

Así pues el coste sería:

  • Coste de API Keys → Coste bajo
  • Coste Integración con Autentificación Keycloak → Coste medio (aumenta la complejidad del software en caso de ser necesaria)
  • Coste por solapamiento. → Coste alto 
  • Coste de operación→ Coste medio


UI Expand
titleAlternativa 2

Realmente esta alternativa es una expansión de la alternativa 1. en esta alternativa  plantea lo siguiente "Incluir una autorización por cada sistema productor. En este caso habría que disponer de una persistencia que almacenara API-KEY, sistema y eventos autorizados a logar. Esta alternativa es más elegante aunque más costosa, y permite un grano más fino de autenticación y autorización."

UI Expand
titleVentajas
  • Fácil implementación: Las API Keys son fáciles de implementar y utilizar.
  • Escalabilidad: Las API Keys son escalables y pueden ser utilizadas para gestionar un gran número de sistemas terceros.
  • Coste: Las API Keys son una solución de bajo coste.
  • Grano fino de autorización
UI Expand
titleDesventajas
  • Requiere gestión: Las API Keys requieren una gestión adecuada para evitar que sean utilizadas de forma fraudulenta.
  • No es adecuada para todos los casos: Las API Keys no son adecuadas para casos en los que se requiere una autenticación y autorización más compleja, como la autenticación multifactor.
  • Nivel de seguridad muy básico: La API Key no puede ser revocada fácilmente sin altos costes, dado que es única cualquier sistema que la conozca puede hacer uso de ella para registrar auditoria, y el control es prácticamente inexistente una vez esté entregada al primer proyecto. 
  • Requiere de un software adicional para poder gestionar adecuadamente todas las API-Keys
UI Expand
titleCoste Adopción

Dentro de las ventajas por parte de  se plantea que este sistema es de bajo coste pero no se está contando con la duplicidad que implica la multiplicidad en los sistemas de autenticación, así pues la evaluación de coste que se hace al respecto es la siguiente:

  • Coste de API Keys
  • Coste Integración con Autentificación Keycloak (la autentificación máquina - máquina no es excluyente con usuario - máquina por lo que el sistema destino debe soportar ambas autentificaciones)
  • Coste por solapamiento. Estaríamos tratando la autentificación con dos sistemas diferentes con lo que tenemos duplicidades que complican la operación. 
  • Coste de operación(Es necesario catalogar y administrar los api-key, esta es una tarea fundamentalmente manual)

Así pues el coste sería:

  • Coste de API Keys → Coste bajo
  • Coste Integración con Autentificación Keycloak → Coste medio (aumenta la complejidad del software en caso de ser necesaria)
  • Coste por solapamiento. → Coste alto 
  • Coste de operación→ Coste medio


UI Expand
titleAlternativa 3
En esta alternativa planteamos el uso de Keycloak, concretamente la creación de clientes con autentificación basada en clientId y secret. En esta alternativa el productor solicita un token mediante el uso del client Id y un secret y a partir de ese momento usa el token para la comunicación mediante el estándar oauth2.0.
UI Expand
titlePosibilidades
  • Autenticación y autorización: Los ClientId - Secrets permiten autenticar y autorizar a un sistema tercero generando un token de acceso a los recursos del sistema que estén autorizados.
  • Autorización: Los ClientId - Secrets permiten autorizar a un sistema tercero a acceder a los recursos del sistema.
  • Flexibilidad: Los ClientId - Secrets pueden ser utilizadas para restringir el acceso a los recursos del sistema en función de las necesidades de cada sistema tercero.
  • Seguridad: Los ClientId - Secrets pueden ser utilizadas para proteger los recursos del sistema de accesos no autorizados.
  • Revocación: El uso de clientes y tokens oauth garantizan la posibilidad de revocación.
  • Estándares de seguridad: Keycloak se integra con Oauth1.0, Oauth2.0, SAML.
UI Expand
titleVentajas
  • Fácil implementación: Los clientes Keycloak son fáciles de implementar y utilizar y mantener. No requiere de herramientas adicionales
  • Escalabilidad: Los clientes Keycloak son escalables y pueden ser utilizadas para gestionar un gran número de sistemas terceros.
  • Coste: Los clientes Keycloak son una solución de bajo coste.
  • Flexibilidad: Permite flujos complejos de autentificación y múltiples sistemas de autentificación.
  • Grano fino de autorización
UI Expand
titleDesventajas
  •  Requiere configuración: Los clientes requieren configuración en Keycloak en el Realm correspondiente.
UI Expand
titleCoste Adopción
  • Coste sistema →No aplica (usa keycloak)
  • Coste Integración con Autentificación Keycloak → No aplica (Es el mismo sistema)
  • Coste por solapamiento. → No aplica (no existen duplicidades ya que solo un sistema)
  • Coste de operación Coste medio (coste de configuración del cliente correspondiente)

Planteamos una pequeña POC de ejemplo

UI Expand
titlePOC Client Id

Planteamos un realm "api". Sobre este realm creamos un cliente "api-n" de tipo OpenID Connect tal y como se muestra en la captura siguiente.


SAS 

Dentro de las configuraciones de las capacidades de este cliente activamos "Client authentication" si deseamos una autorización de grano fino activamos la autorización. a continuación marcamos los flujos de autentificación que deseamos tener activos dentro de los parámetros OAuth2.0.


Una vez que hemos creado nuestro cliente acudimos a la pestaña Credentials, generamos un secret aleatorio e indicamos que la autentificación será mediante  "Client Id and Secret". para una POC no entraremos en más detalles.

Image RemovedImage Added

Cuando hacemos una petición postman para obtener el token podemos ver que la autentificación es correcta.

Image RemovedImage Added

Podemos ver que el contenido del token es correcto y está activo, por lo tanto la autentificación ha sido correcta.

Image RemovedImage Added


El impacto en el microservicio que debe validar el token hay que considerar los siguientes cambios:

Bloque de código
languageyml
titlemicroprofile-config.properties
mp.jwt.token.header=Authorization
mp.jwt.token.cookie=Bearer

 

Bloque de código
titleserver.xml
<feature>microProfile-3.3</feature>


<mpJwt id="defaultmpjwt" jwksUri="https://keycloak.ejemplo.org/auth/realms/sistema-n/protocol/openid-connect/certs" issuer="https://keycloak.ejemplo.org/auth/realms/sistema-n"
	userNameAttribute="azp">
		<audiences>ALL_AUDIENCES</audiences>
</mpJwt>

El método que debe validar el token se debe anotar con:  @RolesAllowed("LISTA-ROLES-AUTORIZADOS")





...