Estratégia de autenticação de microsserviço


138

Estou tendo dificuldades para escolher uma estratégia de autenticação decente / segura para uma arquitetura de microsserviço. A única publicação SO que encontrei no tópico é a seguinte: Logon único na arquitetura de microsserviço

Minha idéia 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 o dele user_id) e a possibilidade de obter o usuário atual idse logado.

Das minhas pesquisas, vejo duas estratégias possíveis:

1. Arquitetura compartilhada

Arquitetura compartilhada

Nesta estratégia, o aplicativo de autenticação é um serviço entre outros. Mas cada serviço deve poder fazer a conversão session_id=>, user_idportanto, deve ser simples. Por isso, pensei em Redis, que armazenaria a chave: valor session_id:user_id.

2. arquitetura de firewall

Arquitetura de firewall

Nesta estratégia, o armazenamento da sessão realmente não importa, pois é tratado apenas pelo aplicativo de autenticação. Em seguida, o user_idpode ser encaminhado para outros serviços. Pensei no Rails + Devise (+ Redis ou cache de memórias, ou armazenamento de cookies etc.), mas há inúmeras possibilidades. A única coisa importante é que o Serviço X nunca precisará autenticar o usuário.


Como essas duas soluções se comparam em termos de:

  • segurança
  • robustez
  • escalabilidade
  • fácil de usar

Ou talvez você sugira outra solução que não mencionei aqui?

Gosto mais da solução nº 1, mas não encontrei muita implementação padrão que me protegesse no fato de estar indo na direção certa.

Espero que minha pergunta não seja fechada. Eu realmente não sei onde mais perguntar.

desde já, obrigado


1
Você poderia fornecer mais detalhes sobre o que você está tentando alcançar? No primeiro caso, a autenticação ocorre contra o Redis ou nos próprios serviços? Redis está faltando no segundo diagrama, isso é intencional?
Plamen Petrov

Eu adicionei algumas informações. Por favor, deixe-me saber que ainda não está claro. Obrigado!
Augustin Riedinger

Você pensou na idéia de criar um microsserviço que use o Protocolo OAuth e o serviço de terceiros que o Token criou?
Tiarê Balbi 16/04/2015

Estou curioso sobre esta solução, mas ainda não entendo como ela funcionará na prática. Você sabe onde eu poderia encontrar algumas implementações padrão dele?
Augustin Riedinger

@AugustinRiedinger, obrigado por colocar isso. Também estou quebrando meu aplicativo da web monolítico em microsserviços dando passos de bebê. No seu caso, os Serviços 1-n são apátridas ou cheios de estado. Caso estejam cheias do estado, você já pensou em gerenciar sessões em cada um desses serviços. Obrigado
Manchanda. P

Respostas:


61

Com base no que entendi, uma boa maneira de resolvê-lo é usando o protocolo OAuth 2 (você pode encontrar um pouco mais de informações sobre isso em http://oauth.net/2/ )

Quando o usuário fizer login no aplicativo, ele receberá um token e, com esse token, poderá enviar para outros serviços para identificá-los na solicitação.

Modelo OAuth 2

Exemplo de design de microsserviço em cadeia Modelo de Arquitetura

Recursos:


1
Obrigado, é bem claro. Eu encontrei este artigo muito bom decomposição praticamente a mesma solução: dejanglozic.com/2014/10/07/...
Augustin Riedinger

16
Sua resposta é ótima, mas como o token gerado pelo API Gateway (de dentro dele ou em um AuthMicroService) pode ser manipulado por um microsserviço aleatório, cujo objetivo não é autenticar, e provavelmente não possui gerenciamento de autenticidade dentro do o código de negócios dele?
Mfrachet

Por exemplo, você pode usar o Netflix Zuul para enviar o token recebido no gateway para todos os serviços e eles saberão as informações do usuário. docs.spring.io/spring-boot/docs/current/reference/htmlsingle/…
Tiarê Balbi

Outra coisa interessante sobre o uso do OAuth2 entre serviços é que você pode ter pontos de extremidade que distinguem entre ações autenticadas pelo serviço e ações autenticadas pelo usuário.
Csp 21/03

2
OAuth é mais sobre conceder acesso ao sistema aos dados de um usuário mantidos em outro sistema. Isso para mim parece um bom argumento para o SAML.
Rob Grant

8

Resposta curta: use a autenticação baseada em token do tipo Oauth2.0, que pode ser usada em qualquer tipo de aplicativo, como um aplicativo da Web ou aplicativo móvel. A sequência de etapas envolvidas para um aplicativo da Web seria então

  1. autenticar no provedor de ID
  2. mantenha o token de acesso no cookie
  3. acessar as páginas no webapp
  4. ligue para os serviços

O diagrama abaixo mostra os componentes que seriam necessários. Essa arquitetura que separa as APIs da Web e dos dados proporcionará uma boa escalabilidade, resiliência e estabilidade

insira a descrição da imagem aqui


O AWS Lambda não fica "frio" e leva tempo para iniciar? Isso tornaria o login lento, não?
tsuz 3/09/19

@tsuz, a AWS agora introduziu o recurso de simultaneidade no lambda, onde você pode reservar a simultaneidade. Com isso, você pode corrigir o problema de partida a frio. docs.aws.amazon.com/lambda/latest/dg/…
Sandeep Nair

Eu adoraria ter visto essa resposta anos antes, é incrivelmente simples entender como a arquitetura de microsserviços com autenticação e autorização microsserviços independentes pode ser orquestrada para dar acesso a outros serviços
brayancastrop

@ Sandeep, acho que você está se referindo à simultaneidade provisionada e não reservada.
Anil Kumar

0

O padrão de gateway da API deve ser usado para implementar isso 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 esse token no banco de dados Redis e definir o cookie no navegador. O gateway da API usará o cookie para validar a solicitação do usuário e enviará o token para os microsserviços.

O API Gateway atua como um ponto de entrada único para todos os tipos de aplicativos clientes, como aplicativos públicos de scripts java, aplicativos tradicionais da Web, aplicativos móveis nativos e aplicativos clientes de terceiros na arquitetura Microservice.

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


-2

você pode usar o servidor 4 de identidade para fins de autenticação e autorização

você deve usar o Firewall Architecture para ter mais controle sobre segurança, robustez, escalabilidade e facilidade de uso

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.