Estratégia de autenticação de Microservice

Estou a ter dificuldade em escolher uma estratégia de autenticação decente e segura para uma arquitectura de micro-serviços. O único post que encontrei sobre o tema é este: sinal único na arquitetura Microservice

A minha ideia aqui é ter em cada serviço (por exemplo. autenticação, mensagens, Notificação, perfil, etc.) uma referência única para cada usuário (logicamente então seu user_id) e a possibilidade de obter o usuário atual id se logado.

Das minhas pesquisas, Vejo que há duas estratégias possíveis:

1. Arquitectura partilhada

Shared architecture

nesta estratégia, o aplicativo de autenticação é um serviço entre outros. Mas cada serviço deve ser capaz de fazer a conversão session_id => user_id deve ser muito simples. Foi por isso que pensei no Redis, que guardaria a chave:valor session_id:user_id.

2. Arquitectura de Firewall

Firewall architecture

Nesta estratégia, o armazenamento de sessões não importa, pois só é tratado pelo a autenticar app. Então o {[[0]} pode ser encaminhado para outros serviços. Eu pensei em trilhos + Devise (+Redis ou mem-cache, ou armazenamento de biscoitos, etc.) mas há toneladas de possibilidades. A única coisa que importa é que o Service X nunca precisará autenticar o usuário.

como se comparam estas duas soluções em termos de:

  • segurança
  • robustez
  • escalabilidade
  • facilidade de Utilização
Ou talvez sugira outro. solução que não mencionei aqui?

gosto mais da solução #1, mas não encontrei muita implementação padrão que me assegurasse de que estou a ir na direcção certa.

Espero que a minha pergunta não seja encerrada. Não sei mais onde perguntar.

obrigado antecipadamente

Author: Community, 2015-04-15
Source

4 answers

, Baseado no que eu entendo, uma boa maneira de resolver isso é usando o protocolo OAuth 2 (você pode encontrar um pouco mais de informações sobre ele em http://oauth.net/2/)

Quando o seu utilizador entrar na sua aplicação, receberá um token e, com este token, poderá enviar para outros serviços para os identificar no pedido.

OAuth 2 Model

Exemplo de Microservice acorrentada Design Architecture Model

Recursos:

 49
Author: Tiarê Balbi, 2016-09-20 16:11:38

Resposta Curta: Use o OAuth2. 0 kind token based authentication, que pode ser usado em qualquer tipo de aplicações como um webapp ou uma aplicação móvel. A sequência de passos envolvidos para uma aplicação web seria então para

  1. autenticar contra o fornecedor de ID
  2. mantém a ficha de acesso em cookie
  3. acesse as páginas do webapp
  4. Ligue para os serviços

O diagrama abaixo mostra os componentes que seriam necessários. Tal arquitetura separando a web e a apis de dados dará uma boa escalabilidade, resiliência e estabilidade

enter image description here

 1
Author: Sandeep Nair, 2018-03-07 23:48:00

Pode utilizar um servidor de identificações 4 para fins de autenticação e autorização

Tem de usar Arquitectura de Firewall por isso tem mais controlo sobre segurança , robustez ,escalabilidade e facilidade de Utilização

 0
Author: Vijay Parmar, 2017-08-17 08:42:47

O padrão de gateway da API deve ser usado para implementar isto usando o OpenID Connect. O Usuário será autenticado pelo IDP e receberá o token JWT do servidor de autorização. Agora o sistema de gateway da API pode armazenar este token na base de dados Redis e definir o cookie no navegador. A API gateway usará o cookie para validar o pedido do Usuário e enviará o token para os Microservices.

A 'Gateway' da API funciona como um ponto de entrada único para todos os tipos de clientes, aplicações como a aplicação cliente de 'script' java pública, aplicativo Web tradicional, aplicativo móvel nativo e aplicativos clientes de terceiros na arquitetura Microservice.

Você pode encontrar mais detalhes sobre isso em http://proficientblog.com/microservices-security/

 0
Author: ManishSingh, 2018-01-09 20:45:04