Termino esta serie, exponiendo un caso de uso, una web que consume un API y esta a su vez tiene varios servicios de dominio (que resuelven problemas del negocio). El dibujo es más o menos el siguiente.
Tenemos una aplicación web, que podría ser un Single Page Application, código JavaScript que se ejecutará en el navegador. Aquí se le pedirá al usuario que se autentique. Tras meter el usuario y la password se obtendrá un token JWT y ya estaríamos identificados.
Ahora el usuario consumirá recursos a través del API mandando su identificación y aquí es donde entra en juego las Autorizaciones.
Frontal web (SPA)
Normalmente perfilaremos al usuario, enviándole los menús que puede ver en función de su nivel de autorización. Todo lo que ocurre aquí, se ejecuta bajo el contexto del usuario, en su casa, en su maquina, por lo cual no se puede garantizar la seguridad. Este nivel de autorización es para facilitar la presentación de las funciones que tendrá el usuario.
API
Las llamadas al API ya son el primer punto donde debemos de tomarnos muy en serio la autorización. Si la autenticación la hemos hecho con OAuth u OpenID, ya dispondremos que un primer nivel de autorización, ya que el ámbito del token solo es valido para este API y dispone de unos scopes que podríamos interrogar para denegar o permitir el acceso en los endpoints del API. Es problema es que esto es de grano gordo, es por aplicación no para un usuario concreto.
Así que tras salir airosos de los scopes, en este momento, ya podríamos usar un servidor de autorizaciones para interrogar por el acceso. Al ser un API RESTFUL, encaja toda bastante bien:
El usuario Pepe (sujeto) quiere acceder a /api/recurso1 (recurso) con un GET (operación). ¿Puede o no?
Si se confirma, el flujo de ejecución continua.
Middleware
El API ha concentrado las peticiones hacia las aplicaciones de dominio, va llamando a cada uno de ellos para obtener la funcionalidad, en cada una de estas llamadas se pasara el token, que además de garantizar que el usuario esta autenticado, podremos extraer el sujeto.
Aquí los recursos a proteger suelen ser de negocio, y las acciones están relacionada con la operativa que vamos a realizar sobre ese recurso, una vez más lanzaremos al servidor de autorizaciones la perorata de siempre :
El usuario Pepe (sujeto) quiere acceder al recurso de dominio1 (recurso) para Leer (operación) su contenido. Si dispone de las autorización, le será devuelta una respuesta con la información solicitada.
Backend y otros elementos de infraestructura.
En este nivel, solemos disponer dos autorizaciones, una como servicio, es decir, ¿la aplicación de Dominio 1 puede acceder al servidor de base de datos? ¿Puede enviar mensajes a el servidor de mensajería? Para ello son los propios servicios los que se autentican y solicitan autorización para todos los usuarios.
Y un segundo nivel menos frecuente a nivel de usuario, cuando un servicio de dominio solicita un recurso a Backend, podría pasar el usuario y este se utilizaría para autorizar el acceso a recursos solicitados.
Conclusiones
Autorizaciones es critico, y no es trivial cuando quieres disponer de un servicio centralizado, que sirva para muchos casos de uso, y que no se convierta en un caos administrativo.
Vimos que existe un estándar, XACML, que nos da las pautas para definir políticas y una arquitectura que tiene en cuenta todos los elementos a proteger. Mejor no ser muy creativo, seguir este estándar nos hará vivir mas seguros
¡A darle caña! ?