Eine eingehende Analyse der Methode zur Implementierung von SSO Single Sign-On in PHP

SSO ist in mehreren Anwendungssystemen verfügbar. Benutzer müssen sich nur einmal anmelden, um auf alle gegenseitig vertrauenswürdigen Anwendungssysteme zuzugreifen. Wie implementiert man also SSO-Single-Sign-On in PHP? Der folgende Artikel gibt Ihnen eine detaillierte Einführung in die Implementierung von Single Sign-On SSO.

SSO (Single Sign On), also Single Sign-On, ist eine Art Zugriffsberechtigung, die mehrere verwandte, aber unabhängige Systeme steuert. Benutzer mit dieser Berechtigung können eine einzige ID und ein einziges Passwort verwenden, um auf ein bestimmtes oder ein bestimmtes System zuzugreifen Mehrere Systeme, um die Verwendung unterschiedlicher Benutzernamen oder Passwörter zu vermeiden, oder eine Konfiguration zur nahtlosen Anmeldung bei jedem System.

Bei großen Systemen kann die Verwendung von Single Sign-On den Benutzern viel Ärger ersparen. Nehmen wir zum Beispiel Baidu. Es gibt viele Subsysteme unter Baidu – Baidu Experience, Baidu Knows, Baidu Library usw. Wenn wir diese Systeme verwenden, müssen wir für jedes System einen Benutzernamen und ein Passwort eingeben, um uns einmal anzumelden Erfahrung wird definitiv sinken.

Zwei Elemente, die mit SSO interagieren: 1. Benutzer, 2. System. Seine Eigenschaften sind: Ein Login, alle Zugriffe. SSO ist eine Art Zugriffskontrolle, die steuert, ob sich Benutzer anmelden können, d . Benutzer, 2. System, 3. Authentifizierungscenter.

1. So führen Sie Single Sign-On für dieselbe Domäne, aber unterschiedliche Subdomänen durch

Angenommen, unsere Website wird gemäß dem folgenden Domänennamen bereitgestellt:

• sub1.onmpw.com
• sub2.onmpw .com

Diese beiden Websites teilen sich die gleiche Domain auf mpw.com.

Standardmäßig sendet der Browser das Cookie an den Host, der der Domäne entspricht, zu der es gehört. Mit anderen Worten: Die Standarddomäne für Cookies von sub1.onmpw.com ist .sub1.onmpw.com. Daher erhält sub2.onmpw.com keine Cookie-Informationen, die zu sub1.onmpw.com gehören. Weil sie sich auf unterschiedlichen Hosts befinden und auch ihre Subdomains unterschiedlich sind.

1.1 Legen Sie die Cookie-Informationen der beiden unter derselben Domain fest.

• Melden Sie sich beim sub1.onmpw.com-System an.
• Nach erfolgreicher Anmeldung wird ein eindeutiger Identifikator-Token generiert (wenn Sie den Token kennen, wissen Sie, welcher Benutzer ist angemeldet). Cookie-Informationen festlegen. Hierbei ist zu beachten, dass das Token im Cookie gespeichert wird, beim Setzen jedoch die Domäne, zu der dieses Cookie gehört, auf die Top-Level-Domäne .onmpw.com festgelegt werden muss. Hier kann die Funktion setcookie verwendet werden. Der vierte Parameter dieser Funktion dient zum Festlegen der Domäne des Cookies.

setcookie(‘token’, ’xxx’, '/', ’.onmpw.com’);复制代码

• Greifen Sie auf das sub2.onmpw.com-System zu und der Browser sendet zusammen mit der Anfrage das Informationstoken im Cookie an das sub2.onmpw.com-System. Zu diesem Zeitpunkt prüft das System zunächst, ob die Sitzung angemeldet ist. Wenn Sie nicht angemeldet sind, überprüft es das Token im Cookie, um eine automatische Anmeldung zu erreichen.

• sub2.onmpw.com Sitzungsinformationen nach erfolgreicher Anmeldung schreiben. Für eine zukünftige Überprüfung verwenden Sie einfach Ihre eigenen Sitzungsinformationen, um sie zu überprüfen.

1.2 Abmelden

Hier besteht das Problem, dass das Sub1-System nach der Abmeldung seine eigenen Sitzungsinformationen und die Cookie-Informationen der Domain .onmpw.com löschen kann. Die Sitzungsinformationen des Sub2-Systems werden nicht gelöscht. Dieser Sub2 ist immer noch angemeldet. Mit anderen Worten: Obwohl mit dieser Methode eine einmalige Anmeldung erreicht werden kann, ist eine gleichzeitige Abmeldung nicht möglich. Der Grund dafür ist, dass sub1 und sub2 zwar Cookies durch die Einstellung der Setcookie-Funktion teilen können, ihre Sitzungs-IDs jedoch unterschiedlich sind und diese Sitzungs-ID auch in Form eines Cookies im Browser gespeichert wird, die Domäne, zu der sie gehört, jedoch nicht .onmpw ist .com.

Wie kann man dieses Problem lösen? Wir wissen, dass in diesem Fall dieses Problem gelöst werden kann, solange die Sitzungs-ID der beiden Systeme identisch ist. Mit anderen Worten: Die Domäne, zu der die Cookie-speichernde Sitzungs-ID gehört, ist ebenfalls .onmpw.com. In PHP wird sessionId nach dem Aufruf von session_start() generiert. Wenn Sie möchten, dass sub1 und sub2 dieselbe Sitzungs-ID haben, müssen Sie vor session_start() die Domäne festlegen, zu der die Sitzungs-ID gehört:

ini_set('session.cookie_path', '/');
ini_set('session.cookie_domain', '.onmpw.com');
ini_set('session.cookie_lifetime', '0');复制代码

• 1 Durch die oben genannten Schritte können Sie eine einmalige Anmeldung und Abmeldung von verschiedenen erreichen Domänennamen der zweiten Ebene.
• 2. Wenn die sessionId gleich ist, kann eine einmalige Anmeldung und Abmeldung verschiedener Second-Level-Domainnamen erreicht werden.
• Referenzartikel: https://www.onmpw.com/tm/xwzj/network_145.html

2. So implementieren Sie Single Sign-On zwischen verschiedenen Domänen – CAS

Angenommen, wir müssen das verwenden folgenden Websites Um Single Sign-On zwischen

• www.onmpw1.com
• www.onmpw2.com
• www.onmpw3.com

zu erreichen, funktioniert die obige Lösung nicht.

Es gibt derzeit eine Open-Source-SSO-Lösung auf Github. Das Implementierungsprinzip ähnelt dem des Mainstream-SSO: https://github.com/jasny/sso

Kernprinzip:

• 1. Der Client greift auf verschiedene Subsysteme zu und das dem Subsystem entsprechende SSO-Benutzerservicecenter verwendet dieselbe SessionId.
• 2. Der Subsystem-Broker und der Server sind durch Anhängen an den Autorisierungslink gebunden.

Derselbe Stammdomänenname muss nicht jedes Mal zum Autorisierungsdienst springen. aber die Domäne ist angegeben, solange einer der gleichen Stammdomänennamen erfolgreich autorisiert wurde, können alle dieses Cookie beim nächsten Mal nicht erneut autorisieren und Benutzerinformationen können direkt angefordert werden.

Erster Besuch A:

Zweiter Besuch B:

2.1 Beurteilung des Anmeldestatus

Nachdem sich der Benutzer beim Zertifizierungszentrum angemeldet hat, wird eine Vereinbarung zwischen dem Benutzer und getroffen Im Zertifizierungszentrum wird eine Sitzung gestartet, wir nennen diese Sitzung globale Sitzung. Wenn der Benutzer anschließend auf die Systemanwendung zugreift, ist es für uns unmöglich, zum Authentifizierungszentrum zu gehen, um festzustellen, ob er sich bei jeder Anwendungsanforderung anmelden soll. Dies ist sehr ineffizient und muss bei einer einzelnen Webanwendung nicht berücksichtigt werden.

Wir können eine lokale Sitzung zwischen der Systemanwendung und dem Browser des Benutzers einrichten. Die lokale Sitzung behält den Anmeldestatus des Clients und der Systemanwendung bei. Die globale Sitzung verschwindet Die lokale Sitzung muss verschwinden.

Wenn ein Benutzer auf eine Anwendung zugreift, stellt er zunächst fest, ob die lokale Sitzung vorhanden ist. Wenn sie vorhanden ist, gilt sie als angemeldet und es ist nicht erforderlich, zur Feststellung zum Authentifizierungscenter zu gehen. Wenn sie nicht vorhanden ist, wird an das Authentifizierungszentrum weitergeleitet, um festzustellen, ob die globale Sitzung vorhanden ist. Wenn sie vorhanden ist, wird die Anwendung benachrichtigt und die Anwendung und der Client richten beim nächsten Mal eine lokale Sitzung ein Wenn der Antrag angefordert wird, wird er nicht an das Authentifizierungszentrum weitergeleitet.

2.2 Exit

Wenn der Benutzer ein System verlässt und auf andere Subsysteme zugreift, sollte es sich ebenfalls im Exit-Status befinden. Dazu sollte die Anwendung neben der Beendigung der lokalen Teilsitzung auch dem Authentifizierungscenter mitteilen, dass der Benutzer die Sitzung verlassen hat.

Wenn das Authentifizierungscenter die Beendigungsbenachrichtigung erhält, kann es die globale Sitzung beenden. Wenn der Benutzer auf andere Anwendungen zugreift, wird der abgemeldete Status angezeigt.

Ob es notwendig ist, alle Subsysteme, die lokale Sitzungen eingerichtet haben und ihre lokalen Sitzungen zerstören, sofort zu benachrichtigen, kann je nach Projekt ermittelt werden.

Empfohlenes Lernen: „

PHP-Video-Tutorial“

Das obige ist der detaillierte Inhalt vonEine eingehende Analyse der Methode zur Implementierung von SSO Single Sign-On in PHP. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!