Sistema de autorización y autenticación para microservicios y consumidores

14

Planeamos refactorizar el sistema de nuestra compañía en un sistema basado en microservicios. Estos microservicios serán utilizados por nuestras propias aplicaciones internas de la empresa y por socios externos, si es necesario. Uno para reservar, otro para productos, etc.

No estamos seguros de cómo manejar los roles y los ámbitos. La idea es crear 3 roles de usuario básicos, como administradores, agentes y usuarios finales, y permitir que las aplicaciones del consumidor ajusten los ámbitos si es necesario.

  • Los administradores pueden crear, actualizar, leer y eliminar todos Recursos por defecto (para su empresa).
  • Los agentes pueden crear, actualizar y leer datos para su empresa.
  • Los usuarios finales pueden crear, actualizar, eliminar y leer datos, pero no pueden acceder a los mismos puntos finales que los agentes o administradores. También podrán crear o modificar datos, pero no al mismo nivel que los agentes o administradores. Por ejemplo, los usuarios finales pueden actualizar o leer la información de su cuenta, igual que el agente podrá hacerlo por ellos, pero no pueden ver ni actualizar las notas de administración.

Digamos que los agentes por defecto pueden crear, leer y actualizar cada recurso para su compañía y ese es su alcance máximo que se puede solicitar para su token / sesión, pero los desarrolladores de la aplicación cliente (consumidor de API) han decidido que uno de los sus agentes pueden leer y crear solo ciertos recursos.

Es una mejor práctica manejar esto en nuestra seguridad interna, y permitirles escribir esos datos en nuestra base de datos, o dejar que los clientes se encarguen de eso internamente solicitando un token con menor alcance, y dejar que escriban qué agente tendrá qué alcance en su base de datos? De esta manera, tendríamos que rastrear solo los ámbitos de token.

La desventaja de esto, es que nuestro equipo también tendría que crear mecanismos de acceso afinados en nuestras aplicaciones internas.

Con esta forma de pensar, los microservicios y su sistema de autorización no deben preocuparse por las necesidades de los clientes, ya que son solo consumidores y no forman parte del sistema (aunque algunos de esos consumidores son nuestras propias aplicaciones internas). / p>

¿Es esta delegación un buen enfoque?

    
pregunta Robert 19.08.2016 - 12:51

5 respuestas

13

La autenticación y la autorización son siempre buenos temas

Intentaré explicarle cómo tratamos las autorizaciones en el servicio actual de múltiples inquilinos en el que estoy trabajando. La autenticación y la autorización se basan en token, utilizando el estándar abierto de token web JSON. El servicio expone una API REST a la que puede acceder cualquier tipo de cliente (aplicaciones web, móviles y de escritorio). Cuando un usuario se autentica correctamente, el servicio proporciona un token de acceso que debe enviarse en cada solicitud al servidor.

Entonces, permítame presentarle algunos conceptos que utilizamos en función de cómo percibimos y tratamos los datos en la aplicación del servidor.

Recurso : es una unidad o grupo de datos al que un cliente puede acceder a través del servicio. A todos los recursos que queremos controlar, asignamos un solo nombre. Por ejemplo, teniendo las siguientes reglas de punto final, podemos nombrarlas de la siguiente manera:

product

/products
/products/:id

payment

/payments/
/payments/:id

order

/orders
/orders/:id
/orders/:id/products
/orders/:id/products/:id

Entonces, digamos que hasta ahora tenemos tres recursos en nuestro servicio; product , payment y order .

Acción : es una operación que se puede realizar en un recurso, como, leer, crear, actualizar, eliminar, etc. No es necesario ser solo las operaciones clásicas de CRUD, puede tenga una acción llamada follow , por ejemplo, si desea exponer un servicio que propaga algún tipo de información utilizando WebSockets.

Habilidad : la capacidad de realizar un action en un resource . Por ejemplo; leer productos, crear productos, etc. Básicamente es solo un par de recursos / acciones. Pero también puedes agregarle un nombre y una descripción.

Rol : un conjunto de habilidades que un usuario puede poseer. Por ejemplo, un rol Cashier puede tener las habilidades "leer pago", "crear pago" o un rol Seller puede tener las habilidades "leer producto", "orden de lectura", "orden de actualización", "orden de eliminación".

Finalmente, un usuario puede tener varios roles asignados.

Explicación

Como dije antes, usamos el token web JSON y las habilidades que posee un usuario se declaran en la carga útil del token. Entonces, supongamos que tenemos un usuario con las funciones de cajero y vendedor al mismo tiempo, para una pequeña tienda minorista. La carga útil se verá así:

{
    "scopes": {
        "payment": ["read", "create"],
        "order": ["read", "create", "update", "delete"]
    }
}

Como puede ver en el reclamo scopes , no especificamos el nombre de los roles (cajero, vendedor), en su lugar, solo se especifican los recursos y las acciones que están implicadas. Cuando un cliente envía una solicitud a un punto final, el servicio debe verificar si el token de acceso contiene el recurso y la acción requeridos. Por ejemplo, una solicitud GET para el punto final /payments/88 tendrá éxito, pero una solicitud DELETE para el mismo punto final debe fallar.

  
  • Cómo agrupar y nombrar los recursos y cómo definir y nombrar las acciones y habilidades será una decisión tomada por los desarrolladores.

  •   
  • ¿Cuáles son los roles y qué capacidades tendrán esos roles? son decisiones tomadas por los clientes.

  •   

Por supuesto, debe agregar propiedades adicionales a la carga útil para identificar al usuario y al cliente (inquilino) que emitió el token.

{
    "scopes": {
        ...
    },
    "tenant": "acme",
    "user":"coyote"
}

Con este método, puede ajustar el acceso de cualquier cuenta de usuario a su servicio. Y lo más importante es que no tiene que crear varios roles predefinidos y estáticos, como Administradores, Agentes y Usuarios finales , como señala en su pregunta. Un superusuario será un usuario que posea un role con todo el resources y actions del servicio que se le asigna.

Ahora, ¿qué pasa si hay 100 recursos y queremos un rol que les dé acceso a todos o casi a todos? Nuestra carga útil simbólica sería enorme. Esto se resuelve anidando los recursos y simplemente agregando el recurso principal en el ámbito del token de acceso.

La autorización es un tema complicado que se debe abordar según las necesidades de cada aplicación.

    
respondido por el miso 29.08.2016 - 04:11
3

Creo que, sin importar lo que pase, querrás que tus servicios acepten un token de autenticación proporcionado por un servicio de autenticación que escribes para validar a los usuarios. Esta es la forma más sencilla y segura de evitar el uso incorrecto de sus microservicios. Además, en general, si desea que un cliente tenga una buena experiencia, debe implementar las características críticas usted mismo y realizar pruebas exhaustivas para asegurarse de que las características que ofrece están bien implementadas.

Dado que todas las personas que llaman deben proporcionar a sus microservicios pruebas de que se han autenticado, también puede vincular los permisos a esa autenticación. Si brinda la posibilidad de vincular a un usuario con un grupo de acceso arbitrario (o grupos si desea obtener un diseño sofisticado, aunque es más difícil lidiar con los permisos de agregar y restar), habrá menos preguntas por parte de sus clientes acerca de por qué el usuario x fue capaz de realizar una operación no deseada. En cualquier caso, alguien tiene que hacer una lista de acceso para verificar cada servicio, por lo que también puede ser usted. Es algo que se codificaría muy fácilmente al comienzo de todos los servicios ( if ( !TokenAuthorized(this.ServiceName, this.token) { Raise error } ). También puede hacerlo y hacer un seguimiento de los grupos de usuarios. Es cierto que tendrá que tener un administrador de grupo de permisos y trabajar en la IU de administración de usuarios (usar un grupo existente / crear nuevo para los permisos de usuario). Definir definitivamente los usuarios vinculados a un grupo cuando edite la definición, para evitar confusiones. . Pero, no es un trabajo duro. Solo tenga metadatos para todos los servicios, y enlace la asignación entre el grupo y el servicio en el manejo del token de autenticación.

Bien, hay muchos detalles, pero cada uno de los clientes que quieran esta funcionalidad tendrían que codificar esto en cualquier caso, y si admite los permisos de usuario de tres niveles, también puede extenderlo a Grupos de acceso por usuario. Probablemente, una intersección lógica entre los permisos del grupo base y los permisos específicos del usuario sería la agregación correcta, pero si desea poder agregar y quitar permisos básicos, de los permisos de administrador, agente, base de usuario final, tendría que hacer el indicador de tres estados de uso en los grupos de permisos: Agregar permiso, Denegar permiso, Permiso predeterminado y combinar los permisos de forma adecuada.

(Como nota, todo esto debería suceder sobre algo como SSL o incluso SSL de dos vías si le preocupa la seguridad de ambos extremos de la conversación. Si "filtra" estos tokens a un atacante, está como si hubiera roto una contraseña.)

    
respondido por el BenPen 23.08.2016 - 22:19
1

Mi opinión es que tienes dos opciones aquí.

  • Si solo necesita tener acceso configurable para esencialmente la misma aplicación, entonces haga que los servicios verifiquen los permisos y brinden a sus clientes una interfaz que les permita cambiar los permisos otorgados a cada función. Esto permite a la mayoría de los usuarios utilizar la configuración de roles predeterminada, que los clientes "problemáticos" pueden modificar los roles o crear nuevos para satisfacer sus necesidades.

  • Si sus clientes están desarrollando sus propias aplicaciones, deben presentar su propia API intermedia. El cual se conecta al suyo como administrador, pero verifica la solicitud entrante contra sus propios requisitos de autenticación personalizados antes de llamar a sus servicios

respondido por el Ewan 22.08.2016 - 10:47
1

Consideración de seguridad

Si entiendo bien su diseño, tiene la intención de delegar algunos mecanismos de control de acceso a recursos al lado del cliente, es decir, una aplicación que consume reduce los elementos que un usuario puede ver. Su suposición es:

  

Los microservicios y su sistema de autorización no deben ser molestados   con las necesidades de los clientes, porque son solo consumidores y no son parte de la   sistema

Veo aquí dos problemas serios para negocios serios:

  • ¿Qué sucede si algún usuario malintencionado (por ejemplo, en una de las plantas de su socio) realiza una ingeniería inversa de la aplicación cliente y descubre el API, evita las restricciones que su empresa ha impuesto al cliente y utiliza esa información para dañar su empresa ? Su compañía reclamará daños y perjuicios, pero la compañía de abogados argumentará que usted no proporcionó los medios para proteger sus datos lo suficientemente bien.
  • En general, solo es cuestión de tiempo que los datos confidenciales se utilicen mal (o la auditoría detectará el riesgo) y su administración terminará pidiendo un control más estricto de esos datos.

Es por esto que aconsejaría anticipar tales eventos y atender las solicitudes de autorización. Está en una fase temprana de reingeniería y será mucho más fácil tenerlos en cuenta en su arquitectura (incluso si no los implementa todos) que en el futuro.

Si continúa con su posición actual, consulte al menos a su oficial de seguridad de la información.

Cómo implementarlo

Tienes el truco:

  

De esta manera, tendríamos que rastrear solo los ámbitos de token.

Bien, pretendes usar algunos tokens generales elegidos por el cliente. Una vez más, una debilidad en mi ojo, porque algunos clientes pueden estar fuera de su control.

No sé si ya usa JWT o si usas otras técnicas. Pero si usa JWT, podría tener un token de identidad que transmita la identidad del usuario (e incluso un segundo token que identifique de forma segura la aplicación de origen, lo que podría permitirle diferenciar el nivel de confianza entre los clientes internos y externos). ).

Como pretende ir a una arquitectura de microservicio, me gustaría sugerirle a amke la diferencia entre la administración de usuarios y el proceso de autenticación (que debe ejecutarse como un servicio dedicado) y el control de acceso (que es específico para cada microservicio y debe ser manejado localmente por cada uno de ellos) . Por supuesto, algunos clientes de administración deben proporcionar una visión general completa de varios servicios, para facilitar su uso).

    
respondido por el Christophe 24.08.2016 - 00:48
1

Aquí, hay una respuesta corta también. Debes implementar todas las funciones core que quieres ofrecer a tus "clientes". Parece problemático que los clientes agreguen comportamientos tan fundamentales como los permisos de los usuarios, ya que usted ya está realizando la autenticación de los usuarios; Si deja que el cliente lo implemente, puede terminar "soportando" múltiples implementaciones del mismo código de permisos. A pesar de que no es "propietario", habrá errores en su código y desea que sus clientes tengan la funcionalidad que esperaban, dentro de lo razonable, por lo que respalda la resolución de los problemas que tiene un cliente. Soportar múltiples bases de código no es divertido.

    
respondido por el BenPen 24.08.2016 - 00:17

Lea otras preguntas en las etiquetas