fundo
Amigos que se transformaram de aplicativos monolíticos tradicionais para a Spring Cloud estão me perguntando, como gerenciar as permissões de microsserviço sob Spring Cloud ? Como projetar mais razoavelmente? De uma grande perspectiva, é chamado de permissões de serviço, que são divididas em três partes:用户认证,用户权限e服务校验.
Autenticação do usuário
As aplicações monolíticas tradicionais podem estar acostumadas à existência de sessões. Após os microsserviços da Spring Cloud, as sessões podem ser resolvidas por sessões distribuídas, mas elas não são a melhor estratégia, afinal. Algumas pessoas começaram a implementar a segurança da nuvem da primavera combinada com OAuth2 , o que é bem conhecido por seu OAuth2. Posteriormente, para otimizar os problemas de armazenamento dos Access Token no OAuth 2 e melhorar a disponibilidade e escalabilidade dos serviços de back-end, existe um método de verificação de token melhor ( JWT Web Token). Uma coisa a enfatizar aqui é que OAuth2 e JWT não são comparáveis, eles são duas coisas completamente diferentes.
OAuth2是一种授权框架, enquanto JWT é um protocolo de autenticação
OAuth2 Authentication Framework OAuth2 contém quatro funções:
OAuth2 contém 4 modos de autorização
Entre eles, o processo de operação do OAuth2 é mostrado na figura abaixo, extraída da RFC 6749:
+--------++------------------------+| |-(a)-Solicitação de autorização-> | Recurso || | | | | Proprietário || | <-(b)-Grant de autorização --- | || | +--------------------------+| || | +---------------------+| |-(c)-Grant de autorização-> | Autorização || Cliente | | | Servidor || |<-(D)--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ----->| Recurso || | | Servidor || <-(f) --- Recurso protegido --- | |+--------++------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
No Spring Cloud OAuth2, todos os pedidos para acessar os recursos de microsserviço carregam tokens no cabeçalho HTTP. O serviço acessado solicitará ao servidor de autorização que verifique a validade do token. Dessa forma, precisamos de两次或者更多次solicitações. Toda a verificação da validade do token se enquadra no servidor de autorização, que se tornou um gargalo muito grande para a expansão horizontal do nosso sistema.
Protocolo de certificação JWT
授权服务器serializa as informações do usuário e o escopo da autorização e coloca uma string json, usa Base64 para codificá -la e, finalmente, assina a string com uma chave privada no servidor de autorização para obter um JSON Web Token .
Supondo que todos os outros servidores de recursos mantenham uma chave pública da RSA. Quando o servidor de recursos recebe a solicitação para ter um token no cabeçalho HTTP, o servidor de recursos pode obter o token e verificar se ele usa a assinatura de chave privada correta (se foi assinada pelo servidor autorizado, ou seja, verificação de assinatura). Após a passagem da verificação, as informações de verificação válidas contidas no TOEKN serão obtidas após a desserialização.
Entre eles, o principal fluxograma da operação é o seguinte:
+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Através do método acima, podemos concluir bem a autenticação do usuário baseada em serviço.
Permissões de usuário
Todo mundo gosta de shiro para o bloqueio de permissão de aplicativos tradicionais de corpo único, e é muito fácil de usar. Mas uma vez divididos, as permissões começam a ser espalhadas pelas várias APIs. shiro ainda está funcionando? No projeto, eu não usei shiro . Depois que as extremidades dianteiras e traseiras são separadas, a interação é token, os serviços de back-end são sem estado, os botões front-end são com recursos e onde podemos gerenciar as permissões?
Resumo e design
Antes de introduzir o design do núcleo flexível, deixe-me apresentar um conceito de visualização: RBAC (controle de acesso baseado em função, controle de acesso baseado em função), o que significa que os usuários se associam a permissões por meio de funções. Simplificando, um usuário tem várias funções e cada função tem várias permissões.
O RBAC é na verdade um modelo analítico, dividido principalmente em: modelo básico RBAC0 (RBAC do núcleo), modelo hierárquico de função RBAC1 (hierarqual RBAC), modelo de restrição de função RBAC2 (restrição RBAC) e modelo unificado RBAC3 (combina RBAC).
Core UML
Este é o diagrama de relacionamento abstrato do Autor RBAC após vários cenários de negócios
Descrição da classe
Grupo
Um grupo ou grupo, uma coleção com um certo número de permissões, também pode ser um portador de permissões.
子类: usuário (usuário), função (função), posição (post), unidade (departamento). Através da composição específica do usuário, grupos ou grupos de diferentes cenários de negócios são formados, e as permissões dos usuários são obtidas por meio de autorização para a classe pai do grupo ou grupo.
Permissão
As permissões, integração com um certo número de recursos, também podem ser o portador de recursos.
Recursos
Existem recursos sob permissões e as fontes de recursos incluem: menu (menu), botão (permissão de ação), elementos da página (botão, guia, etc.), permissões de dados, etc.
Programa
Os programas, a transportadora de renderização para controles de permissão relacionados, podem ser montados em vários menus.
Composição básica de programas da Web comuns
A relação entre modelo e microsserviços
Se todas as interfaces da API após o serviço de nuvem da primavera forem definidas como Resources acima, podemos ver essa situação.
Por exemplo, se um usuário adicionar, excluir, modifys e verificações, nossa página fará isso.
| Elementos da página | Codificação de recursos | Recurso URI | Método de solicitação de recurso |
|---|---|---|---|
| Consulta | user_btn_get | /api/user/{id} | PEGAR |
| Aumentar | user_btn_add | /API/Usuário | PUBLICAR |
| editar | user_btn_edit | /api/user/{id} | COLOCAR |
| excluir | user_btn_del | /api/user/{id} | EXCLUIR |
Depois de abstrair o relacionamento de mapeamento acima, nossos recursos da frente e de trás são referenciados, facilitando a autoridade das permissões do grupo de usuários. Por exemplo, concordo permissão a um usuário para adicionar e excluir. No前端precisamos apenas verificar se a资源编码existe ou não para controlar a tela e o esconderijo dos botões, enquanto no后端, precisamos apenas interceptar e determinar uniformemente se o usuário possui URI e请求方式correspondente.
Quanto a se a interceptação de permissão unificada é colocada no gateway Zuul ou colocada no interceptador do serviço de back -end específico (filtro, inteceptor), ele pode ser facilmente implementado. Não limitado à invasividade do código. O fluxograma de colocar Zuul é o seguinte:
Se a interceptação unificada das permissões for colocada em Zuul , haverá um problema, ou seja, se o serviço de back-end é seguro e o serviço só precisará ser chamado através do Centro de Registro. Isso envolve o terceiro módulo por trás, autenticação entre serviços.
Autenticação entre serviços
Porque todos sabemos que os serviços são chamados diretamente de procedimentos remotos depois que eles encontram o cliente através do Centro de Registro. Precisamos proteger cada serviço e interface sensível na produção. O processo do tópico é o seguinte:
O método de implementação do autor é baseado no FeignClient Inteceprot da Spring Cloud (aplique automaticamente o token de serviço, passe no contexto atual) e Mvc Inteceptor (verificação do token de serviço, atualize o contexto atual) para proteger ainda mais a segurança do serviço.
Depois de combinar as características do Spring Cloud, o fluxograma geral é o seguinte:
Ponto de otimização
Embora a segurança da interface da API seja garantida através da verificação de legalidade do usuário acima mencionada, interceptação de permissão do usuário e autenticação entre serviços, Http访问频率é relativamente alta. Quando o número de solicitações aumentar, o problema da慢será particularmente óbvio. Certas estratégias de otimização podem ser consideradas, como cache de permissão do usuário, distribuição e armazenamento misto de informações de autorização de serviço e atualização regular dos tokens de autenticação de serviço.
Conclusão
O exposto acima é minha ideia geral no projeto. Amigos interessados podem aprender com meu projeto de código aberto. Bem -vindo ao Star:
- Gitchina: https://gitee.com/minull/ace-security (JWT, permissões de usuário)
- Github: https://github.com/wxiaoqi/ace-security
- Gitchina: http://git.oschina.net/geek_qi/ace-gate (autenticação de serviço)
O exposto acima é todo o conteúdo deste artigo. Espero que seja útil para o aprendizado de todos e espero que todos apoiem mais o wulin.com.