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 gibt es häufig viele Anwendungssysteme, z Taobao, Tmall, Aitaobao 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 mehrere Sätze von Benutzernamen und Passwörtern gleichzeitig 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:
Praktisch für Benutzer: Aus Sicht 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. Als weiteres Beispiel verfügen viele Unternehmen ü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 Domäne)?
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 Verwaltungsschwachstellen 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
Gemeinsamen Cookies
Wenn sich unsere Subsysteme alle unter einem übergeordneten Domänennamen befinden, können wir Cookies unter der übergeordneten Domäne platzieren , Cookies unter demselben Domänennamen können von Browsern gemeinsam genutzt werden, sodass die Sitzungs-ID des Benutzers über den Cookie-Verschlüsselungs- und Entschlüsselungsalgorithmus abgerufen werden kann, 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:
Der Benutzer greift auf a zu Bestimmtes Subsystem und stellt fest, dass der Benutzer zur SSO-Anmeldeseite weitergeleitet wird.
c zur Rückrufadresse und Rückgabe des Authentifizierungstickets;
d Wenn der Benutzer nicht angemeldet ist, springt der Authentifizierungspass zur Rückrufadresse und sendet das Authentifizierungsticket zurück. Das Subsystem ruft das Ticket ab, ruft SSO auf, um die Benutzer-UID usw. zu erhalten, und ermöglicht dem Benutzer nach Erfolg die Anmeldung.
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, um einige Daten an den Client zu schreiben , Set- Das
Domänenfeld im Cookie wird verwendet, um die Domäne anzugeben, in der sich das Cookie befindet.
Chestnut:
Wir besuchen www.cookieexm.com. Wenn der Server Set-Cookie zum Rückgabeheader hinzufügt und die Domäne nicht angegeben ist, ist die Standarddomäne dieses Cookies www .cookieexm.com, d. h. der Client sendet 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 im Cookie 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.b2 **.c1 Um Single Sign-On zwischen .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. Nehmen Sie www.a1.a2 als Beispiel:
Sehen Sie sich die Funktionen 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 bietet Es erscheint ein Anmeldefenster 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 gelöst werden
Wie man eine große Menge temporärer Vertrauensdaten effizient speichert
Wie man verhindert, dass der Informationsübertragungsprozess manipuliert wird
So stellen Sie sicher, dass das SSO-System dem Anmeldesystem und dem Bintang-System vertraut
Für das erste Problem können Sie im Allgemeinen eine verteilte Cache-Lösung ähnlich wie Memcached verwenden, die nicht nur einen Mechanismus zum Erweitern der Datenmenge bereitstellen kann, sondern auch Bieten Sie auch einen effizienten Zugriff. Für das dritte Problem werden im Allgemeinen zwei digitale Signaturen verwendet, entweder durch digitale Zertifikatsignaturen oder durch Methoden wie MD5. Dies erfordert, dass das SSO-System die Parameter verschlüsselt, die mit MD5 überprüft werden müssen Wenn Sie die Anmelde-URL zurückgeben und diese mit dem Token zurückgeben, muss das anzumeldende System schließlich an das SSO-System übergeben werden, um festzustellen, ob die Informationen vorhanden sind geändert durch Überprüfung des Tokens
Für die letzte Frage können Sie einfach sagen, dass nur Systeme auf der Whitelist Produktionsvertrauensbeziehungen anfordern können. Ebenso können nur Systeme auf der Whitelist von der Anmeldung ausgenommen werden.
Weitere Artikel zur Analyse und Implementierung von SSO-Cookie-Anmeldungen in PHP finden Sie auf der chinesischen PHP-Website!
