fondo
Los amigos que se han transformado de aplicaciones monolíticas tradicionales a Spring Cloud me preguntan, ¿cómo administrar los permisos de microservicio en Spring Cloud ? ¿Cómo diseñar más razonablemente? Desde una gran perspectiva, se llama permisos de servicio, que se dividen en tres partes:用户认证,用户权限y服务校验.
Autenticación de usuario
Las aplicaciones monolíticas tradicionales pueden estar acostumbradas a la existencia de sesiones. Después de los microservicios de Spring Cloud, las sesiones se pueden resolver mediante sesiones distribuidas, pero después de todo no son la mejor estrategia. Algunas personas comenzaron a implementar la seguridad de Spring Cloud combinada con OAuth2 , que es conocida por su OAuth2. Más tarde, para optimizar los problemas de almacenamiento de Access Token en OAuth 2 y mejorar la disponibilidad y la escalabilidad de los servicios de back-end, existe un mejor método de verificación de token JWT (token web JSON). Una cosa para enfatizar aquí es que OAuth2 y JWT no son comparables en absoluto, son dos cosas completamente diferentes.
OAuth2是一种授权框架, mientras que JWT es un protocolo de autenticación
Marco de autenticación OAUTH2 OAUTH2 contiene cuatro roles:
OAUTH2 contiene 4 modos de autorización
Entre ellos, el proceso de operación de OAuth2 se muestra en la figura a continuación, extraída de RFC 6749:
+--------++------------------------+| |-(a)-Solicitud de autorización-> | Recurso || | | | | Propietario || | <-(b)-Subvención de autorización --- | || | +------------------------+| || | +-------------------+| |-(c)-Subvención de autorización-> | Autorización || Cliente | | | Servidor || |<-(D)--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ----->| Recurso || | | Servidor || <-(f) --- Recurso protegido --- | |+--------++---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
En Spring Cloud OAuth2, todas las solicitudes para acceder a los recursos de microservicio llevan tokens en el encabezado HTTP. Luego, el servicio al que se accede solicitará el servidor de autorización que verifique la validez del token. De esta manera, necesitamos两次或者更多次solicitudes. Toda la verificación de la validez del token recae en el servidor de autorización, que se ha convertido en un cuello de botella muy grande para la expansión horizontal de nuestro sistema.
Protocolo de certificación JWT
授权服务器serializa la información del usuario y el alcance de la autorización y coloca una cadena JSON, luego usa Base64 para codificarla, y finalmente firma la cadena con una clave privada en el servidor de autorización para obtener un JSON Web Token .
Suponiendo que todos los demás servidores de recursos tendrán una clave pública RSA. Cuando el servidor de recursos recibe la solicitud de tener un token en el encabezado HTTP, el servidor de recursos puede obtener el token y verificar si utiliza la firma de clave privada correcta (si ha sido firmado por el servidor autorizado, es decir, verificación de firma). Después de pasar la verificación, la información de verificación válida contenida en Toekn se obtendrá después de la deserialización.
Entre ellos, el principal diagrama de flujo de operación es el siguiente:
+----------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------------- +----------------------------------------------------------------------------------------------- ---------------------------------------------------------------------------------------------------
A través del método anterior, podemos completar bien la autenticación del usuario basada en servicios.
Permisos de usuario
A todos les gusta shiro para el bloqueo de permisos de aplicaciones tradicionales de un solo cuerpo, y es bastante fácil de usar. Pero una vez dividido, los permisos comienzan a dispersarse en las diversas API. ¿ shiro sigue funcionando? En el proyecto, no usé shiro . Después de que se separan los extremos delanteros y traseros, la interacción es token, los servicios de backend son apátridos, los botones frontales son recursos y ¿dónde podemos administrar los permisos?
Resumen y diseño
Antes de introducir un diseño de núcleo flexible, permítanme presentarle un concepto de vista previa: RBAC (control de acceso basado en roles, control de acceso basado en roles), lo que significa que los usuarios se asocian con los permisos a través de roles. En pocas palabras, un usuario tiene varios roles, y cada rol tiene varios permisos.
RBAC es en realidad un modelo analítico, dividido principalmente en: modelo básico RBAC0 (núcleo RBAC), modelo jerárquico RBAC1 (RBAC jerarqual), modelo de restricción de rol RBAC2 (restricción RBAC) y modelo RBAC3 unificado (combina RBAC).
Core UML
Este es el diagrama de relaciones RBAC abstractas del autor después de múltiples escenarios comerciales
Descripción de la clase
Grupo
Un grupo o grupo, una colección con un cierto número de permisos, también puede ser portador de permisos.
子类: usuario (usuario), rol (rol), posición (post), unidad (departamento). A través de la composición específica del usuario, se forman grupos o grupos de diferentes escenarios comerciales, y los permisos de los usuarios se obtienen mediante autorización a la clase principal del grupo o grupo.
Permiso
Los permisos, la integración con un cierto número de recursos, también pueden ser el transportista de recursos.
Recursos
Hay recursos bajo permisos, y las fuentes de recursos incluyen: menú (menú), botón (permiso de acción), elementos de página (botón, pestaña, etc.), permisos de datos, etc.
Programa
Los programas, el operador de representación para controles de permisos relacionados, se pueden montar en menús múltiples.
Composición básica de programas web comunes
La relación entre modelo y microservicios
Si todas las interfaces API después del servicio de nube de Spring se definen como Resources anteriores, entonces podemos ver tal situación.
Por ejemplo, si un usuario agrega, elimina, modifica y verifica, nuestra página lo hará.
| Elementos de página | Codificación de recursos | Uri de recursos | Método de solicitud de recursos |
|---|---|---|---|
| Consulta | user_btn_get | /API/USER/{ID} | CONSEGUIR |
| Aumentar | user_btn_add | /API/usuario | CORREO |
| editar | user_btn_edit | /API/USER/{ID} | PONER |
| borrar | user_btn_del | /API/USER/{ID} | BORRAR |
Después de abstraer en la relación de mapeo anterior, se hace referencia a nuestros recursos frontales y traseros, lo que nos facilita autorizar los permisos del grupo de usuarios. Por ejemplo, otorgo un permiso de usuario para agregar y eliminar. En前端solo necesitamos verificar si la资源编码existe o no para controlar la pantalla y la ocultación de los botones, mientras que en后端, solo necesitamos interceptar y determinar uniformemente si el usuario tiene URI请求方式URI y correspondiente.
En cuanto a si la intercepción de permiso unificado se coloca en la puerta de enlace Zuul o se coloca en el interceptor del servicio de backend específico (filtro, inteceptor), se puede implementar fácilmente. No limitado a la invasividad del código. El diagrama de flujo de colocar Zuul es el siguiente:
Si la intercepción unificada de los permisos se coloca en Zuul , habrá un problema, es decir, si el servicio de fondo es seguro y el servicio solo debe llamarse a través del centro de registro. Esto implica el tercer módulo detrás, la autenticación entre los servicios.
Autenticación entre servicios
Porque todos sabemos que los servicios se llaman directamente procedimientos remotos después de encontrar al cliente a través del centro de registro. Necesitamos proteger cada servicio e interfaz confidencial en la producción. El proceso del tema es el siguiente:
El método de implementación del autor se basa en FeignClient Inteceprot de Spring Cloud (solicite automáticamente el token de servicio, pase el contexto actual) y Mvc Inteceptor (verificación de token de servicio, actualice el contexto actual) para proteger aún más la seguridad del servicio.
Después de combinar las características de Spring Cloud, el diagrama de flujo general es el siguiente:
Punto de optimización
Aunque la seguridad de la interfaz API se garantiza a través de la verificación de legalidad del usuario mencionada anteriormente, la intercepción de permiso del usuario y la autenticación entre los servicios, Http访问频率es relativamente alta. Cuando aumenta el número de solicitudes, el problema de慢será particularmente obvio. Se pueden considerar ciertas estrategias de optimización, como la memoria caché de permiso del usuario, la distribución y el almacenamiento mixto de la información de autorización del servicio, y la actualización regular de los tokens de autenticación del servicio.
Conclusión
Lo anterior es mi idea general en el proyecto. Los amigos interesados pueden aprender de mi proyecto de código abierto. Bienvenido a Star:
- Gitchina: https://gitee.com/minull/ace-security (JWT, permisos de usuario)
- Github: https://github.com/wxiaoqi/ace-security
- Gitchina: http://git.oschina.net/geek_qi/ace-gate (autenticación del servicio)
Lo anterior es todo el contenido de este artículo. Espero que sea útil para el aprendizaje de todos y espero que todos apoyen más a Wulin.com.