Beispiele zur Erläuterung des Prinzips von SSO Single Sign-On

1. HTTP-Stateless-Protokoll

Die Webanwendung verwendet eine Browser/Server-Architektur und http wird als Kommunikationsprotokoll verwendet. HTTP ist ein zustandsloses Protokoll, das vom Server unabhängig verarbeitet wird und nicht mit vorherigen oder nachfolgenden Anforderungen verknüpft wird. Dieser Vorgang ist in der folgenden Abbildung dargestellt. Es besteht keine Verbindung zwischen den drei Anforderungs-/Antwortpaaren 🎜>

Dies bedeutet aber auch, dass jeder Benutzer über einen Browser auf Serverressourcen zugreifen kann. Wenn Sie bestimmte Ressourcen auf dem Server schützen möchten, müssen Sie Browseranfragen einschränken Sie müssen Browseranfragen identifizieren, auf legitime Anfragen reagieren und illegale Anfragen ignorieren. Um Browseranfragen zu identifizieren, müssen Sie den Browseranfragestatus kennen. Da das http-Protokoll zustandslos ist, lassen Sie Server und Browser gemeinsam einen Zustand aufrechterhalten! Dies ist der Sitzungsmechanismus

2. Sitzungsmechanismus

Wenn der Browser zum ersten Mal den Server anfordert, erstellt der Server eine Sitzung und sendet die Sitzungs-ID als Teil der Antwort an den Browser Der Browser speichert die Sitzungs-ID und übermittelt die Sitzungs-ID in der zweiten und dritten nachfolgenden Anfrage. Der Server erkennt, ob es sich um denselben Benutzer handelt, indem er die Sitzungs-ID in der folgenden Anfrage abruft Es wird das gleiche wie bei der ersten Anfrage generiert.

Der Server speichert das Sitzungsobjekt im Speicher. Sie können sich zwei Möglichkeiten vorstellen:

1. Parameter anfordern

2. Cookie

Verwenden Sie die Sitzungs-ID als Wenn der Server die Anforderung empfängt, kann er für jeden Anforderungsparameter natürlich die Parameter analysieren, um die Sitzungs-ID zu erhalten, und diese verwenden, um festzustellen, ob sie aus derselben Sitzung stammen. Offensichtlich ist diese Methode unzuverlässig. Lassen Sie den Browser dann die Sitzungs-ID selbst verwalten, wenn eine HTTP-Anfrage gesendet wird. Dazu wird der Cookie-Mechanismus verwendet. Cookie ist ein Mechanismus, der vom Browser zum Speichern einer kleinen Datenmenge verwendet wird. Die Daten werden in Form von „Schlüssel/Wert“ gespeichert. Der Browser fügt automatisch Cookie-Informationen hinzu, wenn er eine HTTP-Anfrage sendet.

Der Tomcat-Sitzungsmechanismus implementiert auch Cookies. Wenn Sie den Server ausführen, wird im Browser ein Cookie mit dem Namen „JSESSIONID“ angezeigt. Dabei handelt es sich um die vom Tomcat-Sitzungsmechanismus verwaltete Sitzungs-ID. Der Anforderungsantwortprozess mithilfe von Cookies ist wie folgt

3. Anmeldestatus

Mit dem Sitzungsmechanismus ist der Anmeldestatus leicht zu verstehen, wenn der Browser zum ersten Mal den Server anfordert. Zur Überprüfung der Identität müssen der Benutzername und das Kennwort eingegeben werden. Wenn der Vergleich korrekt ist, bedeutet dies, dass der Benutzer, der diese Sitzung gerade abhält, als legitim gekennzeichnet ist „autorisiert“ oder „angemeldet“ usw. Da es sich um den Status der Sitzung handelt, muss er im Sitzungsobjekt gespeichert werden. Tomcat legt den Anmeldestatus im Sitzungsobjekt wie folgt fest

1 1 2 HttpSession session = request.getSession(); session.setAttribute("isLogin",true); 2

1 2 HttpSession session = request.getSession(); session.getAttribute("isLogin"); HttpSession session = request.getSession();session.setAttribute("isLogin",true);

Wenn der Benutzer erneut zugreift, überprüft Tomcat den Anmeldestatus im Sitzungsobjekt

12	HttpSession session = request.getSession(); session.getAttribute("isLogin");

Das Browser-Anforderungsservermodell, das den Anmeldestatus implementiert, ist in der folgenden Abbildung beschrieben

Der Anmeldestatus im Sitzungsobjekt wird jedes Mal überprüft, wenn eine geschützte Ressource angefordert wird. nur isLogin= Nur auf die wahre Sitzung kann zugegriffen werden, sodass der Anmeldemechanismus implementiert ist.

2. Die Komplexität mehrerer Systeme

Das Websystem hat sich in der Antike längst von einem einzelnen System zu einer aus mehreren Systemen bestehenden Anwendungsgruppe entwickelt Müssen Sie sich nacheinander anmelden und dann nacheinander abmelden? Wie im Bild unten beschrieben

Das Websystem hat sich von einem einzelnen System zu einer Anwendungsgruppe bestehend aus mehreren Systemen entwickelt. Die Komplexität sollte innerhalb des Systems getragen werden, nicht Benutzer. Unabhängig davon, wie komplex das Websystem intern ist, ist es für Benutzer ein einheitliches Ganzes. Das heißt, dass Benutzer, die auf die gesamte Anwendungsgruppe des Websystems zugreifen, dasselbe sind wie der Zugriff auf ein einzelnes System. Nur eine Anmeldung/Abmeldung ist ausreichend 🎜>

Obwohl die Single-System-Login-Lösung perfekt ist, ist sie nicht mehr für Multi-System-Anwendungsgruppen geeignet.

Der Kern der Single-System-Login-Lösung ist das Cookie. Das Cookie trägt die Sitzungs-ID, um den Sitzungsstatus zwischen dem Browser und dem Server aufrechtzuerhalten. Es gibt jedoch Einschränkungen für Cookies. Diese Einschränkung bezieht sich auf die Domäne des Cookies (normalerweise entsprechend dem Domänennamen der Website). Wenn der Browser eine HTTP-Anfrage sendet, überträgt er automatisch Cookies, die mit der Domäne übereinstimmen, nicht alle Cookies >

Warum vereinheitlichen Sie in diesem Fall nicht die Domänennamen aller Subsysteme in der Webanwendungsgruppe unter einem Domänennamen der obersten Ebene, z. B. „*.baidu.com“ und Setzen Sie dann ihre Cookie-Domänen auf „baidu.com“, dieser Ansatz ist theoretisch möglich, und sogar viele frühe Multi-System-Anmeldungen verwendeten diese Methode zum Teilen von Cookies mit demselben Domänennamen.

Nur ​​weil es möglich ist, heißt das jedoch nicht, dass es gut ist, und es gibt viele Einschränkungen beim Teilen von Cookies. Erstens muss der Domänenname der Anwendungsgruppe einheitlich sein; zweitens muss die von jedem System in der Anwendungsgruppe (zumindest dem Webserver) verwendete Technologie identisch sein, andernfalls muss der Schlüsselwert des Cookies (JSESSIONID für Tomcat) identisch sein ) ist anders, die Sitzung kann nicht aufrechterhalten werden und die Methode zum Teilen von Cookies kann nicht über die Grenzen hinweg implementiert werden. Sprachtechnologie-Plattform-Login, wie Java, PHP, .net-System, drittes, das Cookie selbst ist nicht sicher.

Daher benötigen wir eine neue Anmeldemethode, um die Anmeldung von Anwendungsgruppen mit mehreren Systemen zu realisieren, nämlich Single Sign-On

3. Single Sign-On

Was Ist Single Sign-On? Klicken Sie hier, um sich anzumelden? Der vollständige Name von Single Sign-On lautet Single Sign On (im Folgenden als SSO bezeichnet). Dies bedeutet, dass Sie, wenn Sie sich bei einem System in einer Multisystem-Anwendungsgruppe anmelden, in allen anderen Systemen autorisiert werden können, ohne sich erneut anzumelden . Es umfasst Single Sign-On und Single Logout

1. Im Vergleich zum Single-System-Login ist für SSO ein unabhängiges Authentifizierungszentrum erforderlich. Nur das Authentifizierungscenter kann den Benutzernamen und das Passwort akzeptieren Andere Sicherheitsinformationen. Andere Systeme bieten keine Anmeldezugänge. Es werden nur indirekte Autorisierungen durch die Zertifizierungsstelle akzeptiert. Die indirekte Autorisierung wird über Token implementiert. Das SSO-Authentifizierungscenter überprüft, ob der Benutzername und das Passwort des Benutzers in Ordnung sind, und erstellt einen Autorisierungstoken. Im nächsten Sprungprozess wird der Autorisierungstoken als Parameter an jedes Subsystem gesendet und das Subsystem erhält das Das heißt, Sie sind berechtigt, eine Teilsitzungs-Anmeldemethode zu erstellen. Dieser Prozess, der das Prinzip des Single Sign-On darstellt, wird durch die folgende Abbildung veranschaulicht:

Im Folgenden finden Sie eine kurze Beschreibung der obigen Abbildung von System 1. System 1 stellt fest, dass der Benutzer nicht angemeldet ist, springt zum SSO-Authentifizierungscenter und verwendet seine eigene Adresse als Parameter

SSO-Authentifizierungscenter stellt fest, dass der Benutzer angemeldet ist nicht angemeldet, und der Benutzer wird zur Anmeldeseite weitergeleitet

1. Der Benutzer gibt den Benutzernamen und das Passwort ein, um den Anmeldeantrag einzureichen

2. Das SSO-Zertifizierungszentrum überprüft Benutzerinformationen, erstellt Benutzer und führt eine SSO-Authentifizierung durch. Die Sitzung zwischen Zentren wird als globale Sitzung bezeichnet, und gleichzeitig wird ein Autorisierungstoken erstellt.

3. Das SSO-Authentifizierungszentrum wird dies tun Springen Sie mit dem Token zur ursprünglichen Anforderungsadresse (System 1)

4. System 1 erhält das Token und geht zum SSO-Zertifizierungszentrum, um zu überprüfen, ob das Token gültig ist

5. Das SSO-Zertifizierungszentrum überprüft das Token, gibt es als gültig zurück und registriert das System 1

6. System 1 verwendet das Token, um eine Sitzung mit dem Benutzer, genannt, zu erstellen eine Teilsitzung, die die geschützte Ressource zurückgibt

7. Benutzer greift auf System 2 geschützte Ressourcen zu

8. System 2 stellt fest, dass der Benutzer nicht angemeldet ist, springt zum SSO-Authentifizierungscenter und verwendet seine eigene Adresse als Parameter

9. Die SSO-Authentifizierung Das Zentrum stellt fest, dass der Benutzer angemeldet ist. Springen Sie zurück zur Adresse von System 2 und hängen Sie das Token an

10. System 2 erhält das Token und geht zum SSO-Zertifizierungszentrum, um zu überprüfen, ob das Token vorhanden ist ist gültig

11. SSO-Authentifizierungscenter überprüft das Token, gibt gültig zurück, registriert System 2

12. System 2 verwendet das Token, um eine Teilsitzung mit zu erstellen der Benutzer und gibt geschützte Ressourcen zurück

Nachdem sich der Benutzer erfolgreich angemeldet hat, wird eine Sitzung mit dem SSO-Authentifizierungscenter und jedem Subsystem eingerichtet. Die Sitzung wird vom Benutzer mit der SSO-Authentifizierung eingerichtet Das Zentrum wird als globale Sitzung bezeichnet, und die vom Benutzer mit jedem Subsystem eingerichtete Sitzung wird als lokale Sitzung bezeichnet. Nachdem die lokale Sitzung eingerichtet wurde, erfolgt der Zugriff des Benutzers auf die geschützten Ressourcen des Subsystems nicht mehr über die SSO-Authentifizierung Die globale Sitzung und die lokale Sitzung unterliegen den folgenden Einschränkungen:

1. Die lokale Sitzung existiert und die globale Sitzung muss vorhanden sein

2. Globale Sitzung existiert, lokale Sitzung existiert nicht unbedingt

3. Globale Sitzung wird zerstört, lokale Sitzung muss zerstört werden

Sie können Ihr Verständnis von Einzelzeichen vertiefen -on über den Anmeldevorgang von Websites wie Blog Park, Baidu, csdn, Taobao usw. Achten Sie beim Anmeldevorgang auf die Sprung-URL und die Parameter

2. Abmelden

Natürlich , Single Sign-On erfordert auch Single Logout. Wenn Sie sich in einem Subsystem abmelden, werden die Sitzungen aller Subsysteme zerstört.

　Das SSO Das Authentifizierungszentrum hat den Status der globalen Sitzung überwacht. Sobald die globale Sitzung zerstört ist, benachrichtigt der Listener alle registrierten Systeme, Abmeldevorgänge durchzuführen

　Im Folgenden finden Sie eine kurze Erläuterung der obigen Abbildung

1. Der Benutzer initiiert eine Abmeldeanforderung an System 1

2. System 1 erhält das Token basierend auf der zwischen dem Benutzer und System 1 eingerichteten Sitzungs-ID und initiiert eine Abmeldeanfrage an das SSO-Authentifizierungszentrum

3. Das SSO-Zertifizierungszentrum überprüft, ob das Token gültig ist, zerstört die globale Sitzung und ruft alle mit diesem Token registrierten Systemadressen ab

4. Jedes Registrierungssystem empfängt die Abmeldeanforderung vom SSO-Authentifizierungscenter und zerstört die Teilsitzung

5. Das SSO-Authentifizierungscenter leitet den Benutzer zur Anmeldeseite

6. 4. Bereitstellungsdiagramm

Single Sign-On umfasst das SSO-Authentifizierungszentrum und viele Subsysteme. Die Subsysteme und das SSO-Authentifizierungszentrum müssen kommunizieren, um Token und Verifizierungstoken auszutauschen und Initiieren Sie eine Abmeldeanforderung, daher muss das Subsystem den SSO-Client integrieren. Der gesamte Single-Sign-On-Prozess ist im Wesentlichen der Kommunikationsprozess zwischen dem SSO-Client und dem Server

Es gibt viele Möglichkeiten, zwischen dem SSO-Zertifizierungszentrum und dem SSO-Client zu kommunizieren. Hier nehmen wir den einfachen und benutzerfreundlichen httpClient als Beispiel. RPC und Restful API können alle verwendet werden

5. Implementierung

Dies ist nur eine kurze Einführung in den Java-basierten Implementierungsprozess. Der vollständige Quellcode wird nicht bereitgestellt Prinzipiell glaube ich, dass man es selbst umsetzen kann. sso übernimmt die Client/Server-Architektur. Schauen wir uns zunächst die Funktionen an, die von sso-client und sso-server implementiert werden sollen (unten: sso-Zertifizierungsstelle = sso-server)

　sso-client

Fangen Sie die nicht angemeldete Benutzeranforderung des Subsystems ab und springen Sie zum SSO-Authentifizierungszentrum

1. Empfangen und speichern Sie das vom SSO-Authentifizierungszentrum gesendete Token

2. Kommunizieren Sie mit dem SSO-Server und überprüfen Sie die Gültigkeit des Tokens

3. Errichten Sie eine lokale Sitzung

4. Abfangen des Benutzer-Abmeldeanforderung und an SSO senden. Das Zertifizierungszentrum sendet eine Abmeldeanforderung

5. Empfängt die Abmeldeanforderung vom SSO-Zertifizierungszentrum und zerstört die lokale Sitzung

6. SSO-Server

Anmeldeinformationen des Benutzers überprüfen

1. Globale Sitzung erstellen

2. Erstellen Autorisierungstoken

3. Mit SSO-Client kommunizieren und Token senden

4. Überprüfen Sie die Gültigkeit des SSO-Client-Tokens

5. Systemregistrierung

6. Erhalten Sie die SSO-Client-Abmeldeanforderung und melden Sie alle Sitzungen ab

7. Als Nächstes implementieren wir SSO Schritt für Schritt nach dem Prinzip!

1. SSO-Client fängt Nicht-Anmeldeanfragen ab

Es gibt drei Möglichkeiten für Java, Anfragen abzufangen: Servlet, Filter und Listener. Erstellen Sie eine neue LoginFilter.java-Klasse im SSO-Client, implementieren Sie die Filterschnittstelle und fügen Sie das Abfangen nicht angemeldeter Benutzer in der doFilter()-Methode

1 2

3 4 5 6 7 8 9 10 11 12 public void doFilter(ServletRequest request, ServletResponse Response, FilterChain-Kette )wirft IOException, ServletException { HttpServletRequest req = (HttpServletRequest) request;

HttpServletResponse res = (HttpServletResponse) Response; HttpSession session = req.getSession(); if(session.getAttribute("isLogin")) { chain.doFilter(request, Response) ; return; } //Zum SSO-Zertifizierungszentrum springen res.sendRedirect("sso-server-url-with-system - url"); }

2. SSO-Server fängt Nicht-Anmeldeanfragen ab

Fängt Anfragen von SSO ab Client Springen Sie zur Nicht-Anmeldeanforderung des SSO-Authentifizierungscenters und springen Sie zur Anmeldeseite. Dieser Vorgang ist genau derselbe wie bei SSO-Client

3. SSO-Server überprüft Benutzeranmeldeinformationen

Der Benutzer befindet sich auf der Anmeldeseite. Geben Sie den Benutzernamen und das Kennwort ein, fordern Sie die Anmeldung an, das SSO-Authentifizierungscenter überprüft die Benutzerinformationen, die Überprüfung ist erfolgreich und markiert den Sitzungsstatus als „angemeldet“

1 2 3 4 5 6 @RequestMapping("/login") public String login(String username, String password, HttpServletRequest req) {     this.checkLoginInfo(username, password);     req.getSession().setAttribute("isLogin",true);     return"success"; } 1 2 3 1 String token = UUID.randomUUID().toString(); 4 5 1 2 3 4 5 6 7 8 9 10 11 // 请求附带token参数 String token = req.getParameter("token"); if (token != null) {     // 去sso认证中心校验token     booleanverifyResult = this.verify("sso-server-verify-url", token);     if(!verifyResult) {         res.sendRedirect("sso-server-url");         return;     }     chain.doFilter(request, response); } 6

1 2 HttpPost httpPost =new HttpPost("sso-server-verify-url-with-token"); HttpResponse httpResponse = httpClient.execute(httpPost); @RequestMapping("/login") public String login(String username, String passwort , HttpServletRequest req) { this .checkLoginInfo(username, password); req.getSession().setAttribute("isLogin",true); return "success "; } 1 2 3 if (verifyResult) {     session.setAttribute("isLogin",true); } 4. SSO-Server erstellt Autorisierungstoken Der Autorisierungstoken ist eine Folge zufälliger Zeichen Es spielt keine Rolle, wie es generiert wird, solange es sich nur nicht wiederholt und schwer zu fälschen ist. Hier ist ein Beispiel 1 String token = UUID.randomUUID().toString();5. Vom SSO-Client erhaltenes Token und Verifizierung Springen Sie nach der Anmeldung beim SSO-Authentifizierungscenter zurück zum Subsystem und hängen Sie das Token an (sso-client) ruft das Token ab und geht dann zur Überprüfung zum SSO-Authentifizierungscenter in LoginFilter. Fügen Sie ein paar Zeilen zu doFilter() 12 345 67891011 // Anfrage kommt mit Token-ParameterString token = req.getParameter(" token");if (token != null) { // Gehen Sie zum SSO-Zertifizierungszentrum, um das Token zu überprüfen booleanverifyResult = this.verify("sso-server- verify-url", token); if(!verifyResult) { res.sendRedirect("sso-server-url"); return; } chain.doFilter(request, Response);} Die Methode „Verify()“ verwendet httpClient. Die Implementierung wird hier nur kurz vorgestellt. Eine detaillierte Verwendung von httpClient finden Sie im offiziellen Dokument 12 HttpPost httpPost =new HttpPost("sso-server-verify-url-with-token"); HttpResponse httpResponse = httpClient.execute(httpPost);6. SSO-Server empfängt und verarbeitet die Verifizierungstoken-Anfrage Der Benutzer befindet sich in SSO. Nachdem sich das Authentifizierungscenter erfolgreich angemeldet hat, erstellt SSO-Server ein Autorisierungstoken und speichert es Daher überprüft der SSO-Server das Token, um herauszufinden, ob das Token vorhanden ist und ob es abgelaufen ist. Nach erfolgreicher Token-Überprüfung registriert der Server das System, das die Überprüfungsanforderung an das SSO-Zertifizierungszentrum sendet (d. h gespeichert) Das Token und die Adresse des Registrierungssystems werden normalerweise in einer Schlüsselwertdatenbank (z. B. Redis) gespeichert, und Redis kann für den Schlüssel festgelegt werden. Die Gültigkeitszeit ist die Gültigkeitsdauer des Tokens. Redis läuft im Speicher und ist sehr schnell. Es kommt vor, dass der SSO-Server keine Daten speichern muss. Token und Registrierungssystemadressen können in Redis mithilfe der in der folgenden Abbildung beschriebenen Struktur gespeichert werden. Sie fragen sich vielleicht, warum wir die Adressen dieser Systeme speichern müssen. Wenn es nicht gespeichert wird, kann es beim Abmelden zu Problemen kommen. Der Benutzer sendet eine Abmeldeanforderung an das SSO-Authentifizierungszentrum. Das SSO-Authentifizierungszentrum meldet jedoch die globale Sitzung ab um ihre eigenen lokalen Sitzungen einzurichten, noch welche Untersitzungen sie an das SSO-Authentifizierungszentrum senden müssen. Das System sendet eine Abmeldeanforderung, um die Teilsitzung abzumelden 7 . sso-client überprüft das Token und erstellt erfolgreich die Teilsitzung Nach erfolgreicher Token-Überprüfung markiert sso- Der Client die aktuelle lokale Sitzung als „angemeldet“, ändert LoginFilter.java und fügt einige hinzu Zeilen 123 if (verifyResult) { session.setAttribute( "isLogin",true);} SSO-Client muss auch die aktuelle Sitzungs-ID an das Token binden, um anzuzeigen, dass der Anmeldestatus dieser Sitzung mit dem Token zusammenhängt. Diese Beziehung kann mit Java Hashmap gespeichert werden und die gespeicherten Daten werden zur Verarbeitung verwendet Vom SSO-Authentifizierungscenter gesendete Daten 8. Abmeldevorgang Der Benutzer sendet eine Anfrage mit dem Parameter „Abmelden“ (Abmeldeanforderung) an das Subsystem und den SSO-Client Der Interceptor fängt die Anfrage ab und leitet sie an das SSO-Zertifizierungszentrum weiter. Abmeldeanfrage 1 2 3 4 String logout = req.getParameter("logout"); if (logout != null) {     this.ssoServer.logout(token); } 1 2 1 2 3 4 5 6 7 8 @RequestMapping("/logout") public String logout(HttpServletRequest req) {     HttpSession session = req.getSession();     if(session != null) {         session.invalidate();//触发LogoutListener     }     return"redirect:/"; } 3 4 1 2 3 4 5 6 7 8 public class LogoutListener implementsHttpSessionListener {     @Override     publicvoid sessionCreated(HttpSessionEvent event) {}     @Override     publicvoid sessionDestroyed(HttpSessionEvent event) {         //通过httpClient向所有注册系统发送注销请求     } } String logout = req.getParameter("logout"); if (logout != null) { this.ssoServer.logout(token); } Wird auch vom SSO-Zertifizierungszentrum verwendet. Auf die gleiche Weise wird erkannt, dass die Anfrage des SSO-Clients eine Abmeldeanforderung ist (mit dem Parameter „Logout“), und das SSO-Authentifizierungszentrum meldet sich vom globalen System ab Sitzung 12 3 456 78 @RequestMapping("/logout")public String logout(HttpServletRequest req) { HttpSession session = req.getSession(); if(session != null) { session.invalidate();//Trigger LogoutListener } return"redirect:/";} Es gibt ein SSO-Zertifizierungszentrum. Der Zuhörer der globalen Sitzung. Sobald sich die globale Sitzung abmeldet, werden alle registrierten Systeme benachrichtigt, sich abzumelden Tabelle>Verwandte Empfehlungen: Single-Sign-On-Cookie-Analyse in PHP und ImplementierungSingle-Sign-On-Prinzip und einfache ImplementierungSSO Single Sign-On PHP-Implementierungsmethode (Laravel-Framework) 12 345678 öffentliche Klasse LogoutListener implementiertHttpSessionListener { @Override publicvoid sessionCreated(HttpSessionEvent event) { } @Override publicvoid sessionDestroyed(HttpSessionEvent event ) { //Abmeldeanfrage an alle Registrierungssysteme über httpClient senden }}

Das obige ist der detaillierte Inhalt vonBeispiele zur Erläuterung des Prinzips von SSO Single Sign-On. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!