Was bedeutet Single Sign-On?

Single Sign-On SSO bedeutet, dass sich Benutzer in mehreren Anwendungssystemen nur einmal anmelden müssen, um auf alle gegenseitig vertrauenswürdigen Anwendungssysteme zuzugreifen. Dies ist eine der Lösungen für die Unternehmensintegration. Seine Vorteile: 1. Verbessern Benutzereffizienz; 2. Verbesserung der Entwicklereffizienz; 3. Vereinfachung der Verwaltung.

Anfangs hatte ein Unternehmen möglicherweise nur einen Server, aber langsam begann die Anzahl der Server zu steigen. Jeder Server muss registriert und angemeldet sein, und beim Abmelden muss man sich einzeln abmelden. Die Benutzererfahrung ist sehr schlecht! Sie können sich vorstellen, dass es die Leute wirklich zum Zusammenbruch bringen wird, wenn man nach Douban geht und sich bei Douban FM, Douban Reading, Douban Movies, Douban Diary einloggt. Wir wollen ein anderes Anmeldeerlebnis: Für die Dienste eines Unternehmens ist nur eine Registrierung, eine Anmeldung beim Anmelden und eine Abmeldung beim Abmelden erforderlich. Wie geht das?

Einmal registrieren. Es ist nicht schwer, sich einmal zu registrieren. Denken Sie darüber nach, ob es nur darum geht, Benutzerinformationen zwischen Servern zu synchronisieren. Ja, aber diese Beschreibung ist nicht vollständig. Wir werden sie später im Detail erläutern, wenn wir über die Benutzerregistrierung sprechen. Tatsächlich ist die Verwaltung von Benutzerinformationen die eigentliche Schwierigkeit von SSO. Als Anfänger liegt unsere Schwierigkeit jedoch in der Technologie zur Implementierung von SSO. Lassen Sie uns zunächst die Mittel zur Umsetzung besprechen.

Eine Anmeldung und eine Abmeldung. Was ist im Rückblick auf die Geschichte gewöhnlicher Einkaufszentren das Wichtigste, um eingeloggt zu bleiben? Recorder(Sitzung)? Dieses Stück Papier namens Keks? Die auf das Papier geschriebene ID? Es handelt sich um die in der Sitzung aufgezeichneten Informationen und die ID-Cookies sind nicht nur ein Werkzeug zum Aufzeichnen von IDs. Der Client hält die ID und der Server hält die Sitzung, und beide werden zusammen verwendet, um den Anmeldestatus aufrechtzuerhalten. Der Client muss die ID als Anmeldeinformation verwenden, und der Server muss die Sitzung verwenden, um die Gültigkeit der ID zu überprüfen (die ID ist möglicherweise abgelaufen, sie ist möglicherweise überhaupt gefälscht und die entsprechenden Informationen können nicht gefunden werden, der Client entspricht zur ID hat noch keine Anmeldeüberprüfung usw. durchgeführt). Die Sitzung ist jedoch zu Beginn für jeden Server eindeutig, Douban Reading verfügt über eine eigene Sitzung und das Cookie, das die ID aufzeichnet, kann nicht domänenübergreifend sein. Wenn wir uns also einmal an- und abmelden möchten, müssen wir nur einen Weg finden, jeden Server die gleichen Sitzungsinformationen teilen zu lassen, damit der Client diese ID unter jedem Domänennamen halten kann. Darüber hinaus gibt es eine Möglichkeit, die Gültigkeit der ID zu überprüfen und die der ID entsprechenden Benutzerinformationen abzurufen, dh die ID kann überprüft werden

Single-Sign-On-Implementierungsmethode

serverseitig

Basierend darauf, wie die Servergruppe IDs generiert und überprüft, wird sie grob in zwei Typen unterteilt:

„Shared Cookie“ ist für die oben erwähnte Methode zum Teilen von Sitzungen meiner Meinung nach besser, sie „Shared Session“ zu nennen die URL jeder Anfrage. Es wird gesagt, dass diese Methode unsicher ist, deshalb habe ich nicht näher darauf eingegangen. Kann mir jemand einige relevante Informationen empfehlen, die ich später hinzufügen werde? Tatsächlich ist es so, denn der Sitzungsmechanismus ist von Anfang an ein Server für jede Sitzung. Es ist in der Tat etwas seltsam, die Sitzung herauszunehmen und sie von allen Servern gemeinsam nutzen zu lassen.

Die SSO-Token-Methode ist nicht sicher, da es sich um eine Methode zum Teilen von Sitzungen handelt. Daher verwenden wir die Sitzungs-ID nicht mehr als Kennung. Wir generieren eine weitere Kennung und nennen sie SSO-Token (oder Ticket). Diese Kennung ist für die gesamte Servergruppe eindeutig, und alle Servergruppen können das Token überprüfen und die Informationen des Benutzers hinter dem Token erhalten. Was wir besprechen werden, ist auch dieser Weg, und das spezifische Flussdiagramm wird später gezeigt.

Browserseitig

Einmalige Anmeldung hat immer noch einen sehr wichtigen Schritt mit der Art und Weise der Überprüfung des Tokens auf der Serverseite Da es sich immer noch um die aktuelle „Token“-Methode handelt, wird die Identitätsidentifizierung auf der Browserseite mit einem solchen Problem konfrontiert: Nachdem sich der Benutzer erfolgreich angemeldet und das Token (oder die Sitzungs-ID) erhalten hat, wie kann der Browser es speichern und für andere freigeben? Domainnamen? Der gleiche Domänenname ist sehr einfach. Speichern Sie das Token im Cookie und legen Sie den Cookie-Pfad auf den Top-Level-Domänennamen fest, damit alle Subdomänen das Token im Cookie lesen können. So teilen Sie Cookies (dies nennt man geteilte Cookies, das obige sollte geteilte Sitzung heißen). Beispiel: Google, google.com ist der Top-Level-Domainname, mail.google.com für E-Mail-Dienste und map.google.com für Kartendienste sind beide Subdomains. Aber was sollten wir tun, wenn wir domänenübergreifend arbeiten? Google verfügt außerdem über einen Domainnamen, youtube.com, der Videodienste bereitstellt.

Empfohlenes Tutorial: „PHP“

Das obige ist der detaillierte Inhalt vonWas bedeutet Single Sign-On?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!