Analyse und Implementierung von Single-Sign-On-Cookies in PHP

Single Sign-On SSO (Single Sign-On) ist Teil des Identitätsmanagements. Eine gängigere Definition von SSO lautet: SSO bedeutet, dass sich derselbe Benutzer, der in verschiedenen Anwendungen auf demselben Server auf geschützte Ressourcen zugreift, nur einmal anmelden muss, dh nach bestandener Sicherheitsüberprüfung in einer Anwendung kann er dann auf geschützte Ressourcen zugreifen In anderen Anwendungen müssen Sie sich zur Verifizierung nicht mehr erneut anmelden. Ich hoffe, dieser Artikel ist für alle hilfreich.

Was ist SSO?

Single Sign-On SSO (Single Sign-On) ist Teil des Identitätsmanagements. Eine gängigere Definition von SSO lautet: SSO bedeutet, dass sich derselbe Benutzer, der in verschiedenen Anwendungen auf demselben Server auf geschützte Ressourcen zugreift, nur einmal anmelden muss, dh nach bestandener Sicherheitsüberprüfung in einer Anwendung kann er dann auf geschützte Ressourcen zugreifen In anderen Anwendungen ist keine erneute Anmeldung zur Überprüfung erforderlich

Zweck von SSO:

In der aktuellen Unternehmensanwendungsumgebung ist dies häufig der Fall viele Anwendungssysteme wie Taobao, Tmall, Love Taobao und andere Produkte wie Büroautomatisierungssysteme (OA), Finanzverwaltungssysteme, Dateiverwaltungssysteme, Informationsabfragesysteme usw. Diese Anwendungssysteme dienen dem Informationsaufbau des Unternehmens und bringen dem Unternehmen gute Vorteile. Für Benutzer ist die Verwendung dieser Anwendungssysteme jedoch unbequem. Jedes Mal, wenn ein Benutzer das System verwendet, muss er seinen Benutzernamen und sein Passwort zur Identitätsüberprüfung eingeben. Verschiedene Anwendungssysteme verfügen über unterschiedliche Benutzerkonten, und Benutzer müssen sich gleichzeitig mehrere Sätze von Benutzernamen und Passwörtern merken. Insbesondere für Unternehmen mit einer großen Anzahl von Anwendungssystemen und einer großen Anzahl von Benutzern ist dieses Problem besonders ausgeprägt. Die Ursache des Problems ist kein Fehler in der Systementwicklung, sondern ein Mangel an Gesamtplanung und einer einheitlichen Benutzer-Login-Plattform. Der Einsatz der SSO-Technologie kann die oben genannten Probleme lösen

Vorteile von SSO:

Benutzerfreundlichkeit: Betrachtet aus der Perspektive der tatsächlichen Benutzernutzung

Wenn Benutzer das Anwendungssystem verwenden, können sie sich einmal anmelden und es mehrmals verwenden. Benutzer müssen nicht mehr jedes Mal Benutzernamen und Benutzerkennwörter eingeben und sich auch nicht mehrere Sätze von Benutzernamen und Benutzerkennwörtern merken. Eine Single-Sign-On-Plattform kann das Benutzererlebnis bei der Nutzung des Anwendungssystems verbessern.
Praktisch für Administratoren: Aus Sicht der täglichen Wartung und Verwaltung

Viele große Internetunternehmen haben mittlerweile viele Anwendungen, das Folgende ist beispielsweise ein Screenshot von Taobao:

Tmall Juhuasuan Toutiao und andere sind unterschiedliche Anwendungen, und einige verwenden sogar völlig unterschiedliche Domänennamen, aber alle auf Taobao registrierten Benutzer verwenden denselben Satz an Benutzernamen und Passwörtern, wenn Sie Wenn Sie direkt zwischen diesen Systemen wechseln und den Anmeldestatus nicht synchronisieren können, ist die Erfahrung sehr schlecht. Um ein weiteres Beispiel zu nennen: Viele Unternehmen verfügen über viele interne Systeme, wie z. B. HR-Systeme, Finanzsysteme, Anwesenheitssysteme usw. Wenn sich Mitarbeiter bei einem System anmelden und sich anmelden müssen, um zu einem anderen System zu wechseln, ist dies sehr unangenehm. .

Auf dieser Grundlage entstand SSO (Single Sign On). Natürlich gibt es viele Möglichkeiten, diese Anforderung zu erfüllen. Das Hauptproblem, das gelöst werden muss, ist: Cookies können nicht über Domänen hinweg an andere Anwendungen übertragen werden in derselben Anwendung)?

Wenn Sie also mit dem Cookie-Mechanismus nicht vertraut sind, googeln Sie ihn bitte zuerst und verschaffen Sie sich ein allgemeines Verständnis dafür, warum Cookies so konzipiert sind, dass sie nicht domänenübergreifend sind, und andere damit zusammenhängende Probleme.

Systemadministratoren müssen lediglich einen einheitlichen Satz von Benutzerkonten verwalten, was praktisch und einfach ist. Im Gegensatz dazu mussten Systemadministratoren bisher viele Gruppen von Benutzerkonten verwalten. Jedes Anwendungssystem verfügt über eine Reihe von Benutzerkonten, was nicht nur Unannehmlichkeiten für die Verwaltung mit sich bringt, sondern auch anfällig für Verwaltungslücken ist.

Anwendungssystementwicklung vereinfachen: Aus der Perspektive der Anwendungserweiterung betrachten

Bei der Entwicklung eines neuen Anwendungssystems können Sie den Benutzerauthentifizierungsdienst der Single-Sign-On-Plattform direkt nutzen, um die Entwicklung zu vereinfachen Verfahren. Die Single-Sign-On-Plattform realisiert Single-Sign-On durch die Bereitstellung einer einheitlichen Authentifizierungsplattform. Daher muss das Anwendungssystem keine Benutzerauthentifizierungsverfahren entwickeln.
Wie erreicht man das?

SSO bietet die folgenden Möglichkeiten zur Implementierung von

Gemeinsame Cookies

Wenn unsere Subsysteme alle in einem sind Der Browser befindet sich unter dem übergeordneten Domänennamen. Wir können das Cookie unter dem übergeordneten Domänennamen platzieren, sodass die Cookies unter demselben Domänennamen von Browsern gemeinsam genutzt werden können. Auf diese Weise kann die Sitzungs-ID des Benutzers durch die Cookie-Verschlüsselung abgerufen werden Entschlüsselungsalgorithmus, wodurch SSO realisiert wird.

Später stellten wir jedoch fest, dass diese Methode mehrere Nachteile hat:
a. Alle Systeme mit demselben Domänennamen können die SessionID erhalten, die leicht zu ändern ist und unsicher ist; b. Eine plattformübergreifende Domain kann nicht verwendet werden.

Ticketüberprüfung, wir verwenden derzeit diese Methode

Diese Implementierung von SSO umfasst die folgenden Schritte:

a. Der Benutzer greift auf ein bestimmtes Subsystem zu und stellt fest, dass er zur SSO-Anmeldeseite weitergeleitet wird.
c. Wenn der Benutzer bereits angemeldet ist, springen Sie direkt zur Rückrufadresse und geben Sie das Authentifizierungsticket zurück.
d Ticket;
e. Das Subsystem erhält das Ticket und ruft SSO auf. Rufen Sie die Benutzer-UID und andere Informationen ab und lassen Sie den Benutzer sich nach Erfolg anmelden.

Wie bereits erwähnt, geht es bei der Implementierung von SSO über Cookies hauptsächlich darum, wie domänenübergreifende Probleme gelöst werden können. Lassen Sie uns zunächst über das Domain-Attribut in Set-Cookie sprechen.

Cookie-Domäne

Damit das HTTP-Protokoll den Kontext bis zu einem gewissen Grad beibehalten kann, kann der Server Set-Cookie zum Antwortheader hinzufügen Schreiben Sie einige Daten an den Client. Das Feld

Domäne in Set-Cookie wird verwendet, um die Domäne anzugeben, in der sich dieses Cookie befindet.

Chestnut:

Wenn wir www.cookieexm.com besuchen und der Server Set-Cookie zum Rückgabeheader hinzufügt, wenn die Domäne nicht angegeben ist, dann dies Das Cookie wird standardmäßig verwendet. Die Domäne ist www.cookieexm.com. Das heißt, der Client gibt dieses Cookie nur an den Server zurück, wenn er www.cookieexm.com besucht.

Wenn wir die Domäne als .cookieexm.com angeben, kann der Client beim Zugriff auf die folgenden Domänennamen Cookies zurückgeben: www.cookieexm.com www1.cookieexm.com a.cookieexm.com ***.cookieexm.com.

Also ziehen wir eine Schlussfolgerung: Der Client stimmt mit der Domäne des Cookies überein. Auf dieser Basis können wir unser SSO-Login implementieren.

Was bei Cookies zu beachten ist

ist auf „nur http“ eingestellt

Anmeldeinformationen (wie Tickets oder Benutzernamen) sollten verschlüsselt werden

Cookies können keine privaten Daten speichern

Spezifische Lösung

Angenommen, wir benötigen das folgende Subsystem **.a1.a2 **.b1 Um Single Sign-On zwischen .b2 **.c1.c2 zu implementieren, benötigen wir zunächst ein Authentifizierungssystem (sso.s1.s2) speziell für Single Sign-In. Gehen Sie davon aus, dass das System derzeit nicht angemeldet ist, und greifen Sie als Beispiel auf www.a1.a2 zu:

Sehen Sie sich die Auswirkungen der einzelnen Schritte an:

Anfrage www.a1 .a2

www.a1.a2 empfängt die Anfrage und prüft, ob sie das Login-Cookie trägt. Wenn sie sich noch nicht angemeldet hat, wird sie zum SSO-Authentifizierungscenter weitergeleitet

SSO stellt ein Anmeldefenster bereit und der Benutzer gibt den Benutzernamen und das Passwort ein. Das SSO-System überprüft den Benutzernamen und das Passwort

Dieser Schritt ist entscheidend. Bei erfolgreicher Anmeldung wird zunächst das Cookie des SSO-Systems auf dem Client platziert; Informationen werden durch Umleitung an die Geschäftspartei weitergegeben. Beachten Sie, dass diese Übertragung natürlich nicht über Cookies (verschiedene Domänen) erfolgen kann, normalerweise über verschlüsselte Abfragezeichenfolgen.

Das Verifizierungssystem der Geschäftsseite empfängt die SSO-Authentifizierungsinformationen und authentifiziert sich dann.

Nachdem die Geschäftsseite die Authentifizierung bestanden hat, schreibt sie das Cookie des Authentifizierungsergebnisses in .a1.a2. die SSO-Authentifizierung ist abgeschlossen
Weiterleitung zum Geschäftssystem www.a1.a2 Aus der vorherigen Schlussfolgerung können alle Geschäftssysteme, die mit .a1.a2 enden, dieses authentifizierte Cookie

Antwort

Hinweis:

Das Geschäftsauthentifizierungssystem ist möglicherweise nicht vorhanden. Einige Systeme, die nicht zu sensibel sind, können direkt von der SSO-Autorisierung zum Geschäftssystem umgeleitet werden und die SSO-Authentifizierungsinformationen dorthin bringen.

Folgen Sie dem oben Gesagten, wenn der Benutzer zu diesem Zeitpunkt auf die Anwendung www.b1.b2 zugreift, wie in der folgenden Abbildung gezeigt:

ist die Identisch mit dem Zugriff auf www.a1.a2. Der Unterschied besteht darin, dass wir bei der Weiterleitung zur SSO-Autorisierung nicht mehr den Benutzernamen eingeben müssen, da sso.s1.s2 zu diesem Zeitpunkt bereits über Cookies verfügt und die Cookie-Verifizierung direkt verwendet.

Das Obige ist ein einfaches Cookie-basiertes Anmeldesystem.

Mehrere dieser Probleme müssen gezielt angegangen werden

Wie man eine große Menge temporärer Vertrauensdaten effizient speichert

Wie man die Informationen verhindert Übertragungsprozess vor Manipulationen

Wie man dafür sorgt, dass das SSO-System dem Anmeldesystem und dem Bindungssystem vertraut
Für die erste Frage können Sie im Allgemeinen eine verteilte Cache-Lösung ähnlich wie Memcached verwenden, die nicht nur einen Mechanismus bereitstellen kann um die Datenmenge zu erweitern, aber auch einen effizienten Zugriff bereitzustellen

Für die zweite Frage wird im Allgemeinen die digitale Signaturmethode verwendet, entweder durch digitale Zertifikatsignatur oder durch eine Methode wie md5. Dies erfordert die Leistung des SSO-Systems MD5-Verschlüsselung für die Parameter, die bei der Rückgabe der Anmelde-URL überprüft und mit dem Token zurückgegeben werden müssen. Wenn das System, das angemeldet werden muss, die Vertrauensbeziehung schließlich überprüft, muss das Token an das SSO-System übergeben werden Das System kann durch Überprüfung des Tokens erkennen, ob die Informationen geändert wurden. Das letzte Problem kann durch eine Whitelist gelöst werden. Vereinfacht ausgedrückt können nur Systeme auf der Whitelist Produktionsvertrauensbeziehungen anfordern Personen auf der Whitelist können von der Anmeldung ausgenommen werden.

Verwandte Empfehlungen:

Single-Sign-On-Prinzip und einfache Implementierung

Detaillierte Erläuterung der Implementierungsmethoden von drei SSO-Single-Sign-On-Situationen

UCenter Single Sign-On/synchrone Anmeldung/ Beispiele für synchrone Abmeldungen _PHP-Tutorial

Das obige ist der detaillierte Inhalt vonAnalyse und Implementierung von Single-Sign-On-Cookies in PHP. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!