it-swarm.com.de

Microservice-Authentifizierungsstrategie

Es fällt mir schwer, eine angemessene/sichere Authentifizierungsstrategie für eine Microservice-Architektur zu wählen. Der einzige SO Beitrag, den ich zu diesem Thema gefunden habe, ist folgender: Single Sign-On in der Microservice-Architektur

Meine Idee hier ist, in jedem Dienst (z. B. Authentifizierung, Nachrichtenübermittlung, Benachrichtigung, Profil usw.) einen eindeutigen Verweis auf jeden Benutzer (logischerweise dann sein user_id) Und die Möglichkeit zu haben, den Namen der id des aktuellen Benutzers abzurufen, wenn eingeloggt.

Nach meinen Recherchen gibt es zwei mögliche Strategien:

1. Geteilte Architektur

Shared architecture

Bei dieser Strategie ist die Authentifizierungs-App ein Dienst unter anderen. Aber jeder Dienst muss in der Lage sein, die Konvertierung session_id => user_id Durchzuführen, so dass es absolut einfach sein muss. Deshalb habe ich an Redis gedacht, das den Schlüssel speichert: value session_id:user_id.

2. Firewall-Architektur

Firewall architecture

Bei dieser Strategie spielt der Sitzungsspeicher keine Rolle, da er nur von der Authentifizierungs-App verwaltet wird. Dann kann der user_id An andere Dienste weitergeleitet werden. Ich dachte an Rails + Devise (+ Redis oder Mem-Cached, oder Cookie-Speicher usw.), aber es gibt jede Menge Möglichkeiten. Das einzige, was zählt, ist, dass Service X dies niemals tun muss Authentifizieren Sie den Benutzer.


Wie vergleichen sich diese beiden Lösungen in Bezug auf:

  • sicherheit
  • robustheit
  • skalierbarkeit
  • benutzerfreundlichkeit

Oder schlagen Sie vielleicht eine andere Lösung vor, die ich hier nicht erwähnt habe?

Ich mag die Lösung Nr. 1 besser, habe aber nicht viel Standardimplementierung gefunden, die mir die Sicherheit gibt, dass ich in die richtige Richtung gehe.

Ich hoffe, dass meine Frage nicht geschlossen wird. Ich weiß nicht wirklich, wo ich es sonst fragen soll.

Danke im Voraus

115

Nach meinem Verständnis kann das Problem am besten mit dem Protokoll OAuth 2 gelöst werden (weitere Informationen finden Sie unter - http://oauth.net/2/ )

Wenn sich Ihr Benutzer bei Ihrer Anwendung anmeldet, erhält er ein Token und kann es mit diesem Token an andere Dienste senden, um sie in der Anforderung zu identifizieren.

OAuth 2 Model

Beispiel eines verketteten Microservice-Designs Architecture Model

Ressourcen:

55
Tiarê Balbi

Kurze Antwort: Verwenden Sie die tokenbasierte Authentifizierung nach Oauth2.0, die in jeder Art von Anwendung wie einer Webapp oder einer mobilen App verwendet werden kann. Die Reihenfolge der Schritte für eine Webanwendung wäre dann zu

  1. authentifizierung gegen ID-Anbieter
  2. bewahren Sie das Zugriffstoken im Cookie auf
  3. auf die seiten in der webapp zugreifen
  4. rufen Sie die Dienste an

Das folgende Diagramm zeigt die Komponenten, die benötigt würden. Eine solche Architektur, die das Web und die Daten-API trennt, bietet eine gute Skalierbarkeit, Ausfallsicherheit und Stabilität

enter image description here

1
Sandeep Nair

Das API-Gateway-Muster sollte verwendet werden, um dies mit OpenID Connect zu implementieren. Der Benutzer wird von IDP authentifiziert und erhält das JWT-Token vom Autorisierungsserver. Jetzt kann das API-Gateway-System dieses Token in der Redis-Datenbank speichern und das Cookie im Browser setzen. Das API-Gateway überprüft anhand des Cookies die Benutzeranforderung und sendet das Token an Microservices.

API Gateway fungiert als zentraler Einstiegspunkt für alle Arten von Client-Apps wie öffentliche Java Skript-Client-Apps, herkömmliche Web-Apps, native mobile Apps und Client-Apps von Drittanbietern in der Microservice-Architektur.

Weitere Informationen hierzu finden Sie unter http://proficientblog.com/microservices-security/

0
ManishSingh

sie können IDenitty Server 4 für Authentifizierungs- und Autorisierungszwecke verwenden

sie müssen eine Firewall-Architektur verwenden , damit Sie mehr Kontrolle über Sicherheit, Robustheit, Skalierbarkeit und Benutzerfreundlichkeit haben

0
Vijay Parmar