Dieser Artikel vermittelt Ihnen relevantes Wissen zur Authentifizierung. Er stellt hauptsächlich die Implementierungsideen der Authentifizierung in Microservices vor. Gibt es eine gute Lösung, um dies zu erreichen? Schauen wir es uns gemeinsam an, ich hoffe, es wird für alle hilfreich sein.
Einige Freunde haben diese Frage kürzlich auf WeChat gestellt, daher bin ich gekommen, um mit Ihnen zu chatten. Freunde können sie mit meinen vorherigen Artikeln kombinieren um den Code dieses Artikels selbst zu schreiben. Natürlich sind die Ideen nur meine eigenen praktischen Erfahrungen und möglicherweise nicht die perfekteste Lösung. Freunde können gerne in den Kommentaren darüber diskutieren.
Zuallererst wissen Freunde, dass, egal welche Funktionen es gibt, der Kern zwei sind:
Authentifizierung
Autorisierung
Wenn wir uns daher mit Authentifizierungsproblemen in Microservices befassen, können wir auch diese beiden Aspekte berücksichtigen.
Authentifizierung bedeutet, um es ganz klar auszudrücken, Anmelden. Die traditionelle Web-Anmeldung ist eine Cookie+Session-Lösung, die auf den lokalen Speicher des Servers angewiesen ist. Aufgrund der großen Anzahl von Diensten ist diese Lösung offensichtlich nicht mehr geeignet.
Einige Freunde sagen vielleicht, dass die Verwendung von Redis + SpringSession für die Sitzungsfreigabe eine Möglichkeit ist, aber nicht die beste Lösung, da die Leistung und Skalierbarkeit dieser Lösung relativ schlecht sind.
Daher wird empfohlen, Token zur Authentifizierung in Microservices zu verwenden. Sie können JWT-Token wählen, was derzeit auch eine häufig verwendete Lösung ist. Freunde, die mit JWT vertraut sind, wissen jedoch, dass eine reine zustandslose Anmeldung nicht möglich ist, was sehr problematisch ist. Daher reicht es in praktischen Anwendungen nicht aus, es einfach mit Redis zu kombinieren, um das generierte JWT zu konvertieren Eine Kopie der Zeichenfolge wird auch auf Redis gespeichert und die Ablaufzeit festgelegt. Wenn Sie feststellen, ob der Benutzer angemeldet ist, müssen Sie zunächst prüfen, ob die JWT-Zeichenfolge vorhanden ist Wenn die Zeichenfolge erfolgreich analysiert werden kann, liegt kein Problem vor. Wenn die Zeichenfolge nicht erfolgreich analysiert werden kann, bedeutet dies, dass das Token illegal ist.
Diese Art der Mischung von zustandsbehafteter Anmeldung und zustandsloser Anmeldung mag etwas unscheinbar erscheinen, aber im Moment wird dieser Kompromiss als praktikable Lösung angesehen.
Tatsächlich unterscheidet sich die obige Lösung, um es ganz klar auszudrücken, nicht von der herkömmlichen Cookie+Session. Die Ideen werden fast vollständig kopiert: Die traditionelle Sitzung wird durch die traditionelle jsessionId ersetzt, die zwischen dem Server und dem Server wechselt Der Browser ist stattdessen eine JWT-Zeichenfolge. Die herkömmliche jsessionId wird vom Entwickler manuell festgelegt und über den Anforderungsheader übertragen. Die herkömmliche Sitzung kann jedoch automatisch erneuert werden. Jetzt wird die JWT jedoch manuell erneuert Wenn es soweit ist, überprüfen Sie die Ablaufzeit des Tokens auf Redis. Wenn es bald abläuft, wird es einfach zurückgesetzt.
Dies ist das Zertifizierungssystem Ihrer Wahl.
Die Autorisierung in Microservices kann auch über das Shiro- oder Spring Security-Framework erfolgen, was Ärger erspart. In Anbetracht der Tatsache, dass der Microservice-Technologie-Stack ein Produkt der Spring-Familie ist, wird jedem empfohlen, sich zunächst für Spring Security in Bezug auf das Berechtigungsframework zu entscheiden (wenn Freunde mit Spring Security nicht vertraut sind, können Sie im Hintergrund von WeChat auf SS antworten offizieller Account, es gibt Tutorials) .
Wenn Sie Spring Security für komplizierter halten und es selbst tun möchten, können Sie das natürlich tun. Wenn Sie es selbst tun, können Sie auch die Idee von Spring Security nutzen. Eines der jüngsten Projekte von Song Ge sieht folgendermaßen aus:
Nachdem die Anfrage den Microservice erreicht hat, finden Sie zunächst verschiedene Informationen über den aktuellen Benutzer, einschließlich Die Rollen und Berechtigungen des aktuellen Benutzers. Warten Sie auf die Informationen und speichern Sie sie dann im ThreadLocal-Objekt, das an den aktuellen Thread gebunden ist. Passen Sie andererseits Berechtigungsanmerkungen und Rollenanmerkungen an, analysieren Sie diese Anmerkungen in Aspekten und prüfen Sie, ob der aktuelle Benutzer über die erforderlichen Rollen/Berechtigungen usw. verfügt.
Wenn Sie Spring Security verwenden, benötigen Sie für die oben genannten Punkte natürlich keine benutzerdefinierten Anmerkungen. Sie können einfach die mit Spring Security gelieferten Anmerkungen verwenden. Sie können auch umfangreichere Sicherheitsfunktionen in Spring Security nutzen.
Wo erfolgt also die Authentifizierung und Autorisierung?
Lassen Sie uns zunächst über die Authentifizierung sprechen. Die Authentifizierung kann einfach in zwei Schritte unterteilt werden:
Anmeldung
Verifizierung
Im Allgemeinen können wir einen separaten Authentifizierungsdienst für die Anmeldung durchführen. Wenn die Anmeldeanforderung das Gateway erreicht, leiten wir sie an den Authentifizierungsdienst weiter, um den Authentifizierungsvorgang abzuschließen.
Im Authentifizierungsdienst prüfen wir, ob der Benutzername/das Passwort in Ordnung ist und ob der Benutzerstatus in Ordnung ist. Wenn kein Problem vorliegt, generieren wir eine JWT-Zeichenfolge, speichern die Daten in Redis und geben dann die JWT-Zeichenfolge zurück.
Wenn das System über eine Registrierungsfunktion verfügt, wird die Registrierungsfunktion auch auf diesem Microservice ausgeführt.
Verifizierung bezieht sich auf die Überprüfung, ob sich der Benutzer angemeldet hat, wenn jede Anfrage eintrifft.
Natürlich können Sie dies zusammen mit 2.1 tun, aber Brother Song empfiehlt es nicht. Das Problem besteht darin, dass, wenn es sich um eine Anfrage zum Erstellen einer Bestellung handelt, diese Anfrage ursprünglich über das Gateway an den Bestelldienst weitergeleitet wird. Zu diesem Zeitpunkt muss jedoch der Dienst in Abschnitt 2.1 zur Anmeldebestätigung aufgerufen werden Ist kein Problem, wird die Ware weitergeleitet. Dies ist im Hinblick auf den Bestellservice natürlich sehr zeitaufwändig und unzumutbar.
Eine bessere Möglichkeit besteht darin, direkt zu überprüfen, ob das angeforderte Token auf dem Gateway legal ist. Diese Überprüfung selbst ist relativ einfach. Um zu überprüfen, ob das Token legal ist, müssen wir nur prüfen, ob das Token auf Redis vorhanden ist Da das JWT-Token reibungslos analysiert werden kann, kann dieser Vorgang auf dem Gateway durchgeführt werden.
Am Beispiel von Gateway können wir den globalen Filter anpassen und das Token jeder Anfrage im globalen Filter überprüfen. Wenn die Überprüfung erfolgreich ist, wird die Anfrage weitergeleitet, andernfalls wird sie nicht weitergeleitet.
Nach bestandener Überprüfung und Weiterleitung an den jeweiligen Mikrodienst können wir die analysierte Benutzer-ID, den Benutzernamen und andere Informationen in den Anforderungsheader einfügen und diese dann weiterleiten, sodass wir nach Erreichen jedes einzelnen Mikrodienstes wissen, wer ihn gesendet hat Diese Anfrage und welche Rollen/Berechtigungen diese Person hat, um den nächsten Schritt der Berechtigungsüberprüfung zu erleichtern.
Was Song Ge getan hat, ist, ein öffentliches Modul zu definieren. In diesem öffentlichen Modul ist ein Interceptor definiert, der jede Anfrage abfängt, die Benutzer-ID aus dem Anfrageheader herausnimmt und dann abruft Spezifische Benutzerinformationen von Redis und speichern Sie sie in ThreadLocal. Wenn Sie in nachfolgenden Methodenaufrufen feststellen müssen, ob der Benutzer über eine bestimmte Berechtigung verfügt, können Sie diese über ThreadLocal abrufen.
Das ist ungefähr so ein Prozess.
Die Autorisierung kann nicht auf dem Gateway erfolgen, sie muss dennoch auf jedem Mikrodienst durchgeführt werden.
Wir können die Autorisierung von Microservices grob in zwei Kategorien einteilen:
Vom Frontend gesendete Anfragen (externe Anfragen).
Anfragen, die von anderen Microservices gesendet werden (interne Anfragen).
3.2 Interne Anfragen
Wenn interne Anfragen Mikrodienste erreichen, müssen diese natürlich auch authentifiziert werden, genau wie bei der Weiterleitung von Anfragen vom Gateway an jeden einzelnen Mikrodienst. Aber natürlich müssen wir OpenFeign nicht verwenden, um andere anzurufen Bei der Bereitstellung werden eine Reihe von Authentifizierungsinformationen übertragen. Wir können einen OpenFeign-Anfrage-Interceptor definieren. Im Interceptor werden die Anfrage-Header-Informationen einheitlich festgelegt.
Okay, was die Authentifizierung in Microservices betrifft, so machen wir es derzeit. Freunde können gerne eine Nachricht hinterlassen und gemeinsam darüber diskutieren. feign.RequestInterceptor
Mini-Programm-Video-Tutorial
“ „Java-Video-Tutorial“
Das obige ist der detaillierte Inhalt vonEin Artikel, der ausführlich erklärt, wie man die Microservice-Authentifizierung implementiert. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!