PHP-Single-Sign-On-Problem

Ich habe eine einmalige Anmeldung durchgeführt und bin auf ein Problem gestoßen: Es gibt beispielsweise drei Systeme A, B und C. Wenn keine Anmeldung vorhanden ist, wird zur Anmeldung zum S-System gesprungen. Wenn die Anmeldung vorhanden ist Erfolgreich, ein Token wird generiert und übertragen. Wenn Sie zurückkommen, wird das Token in Redis gespeichert. Aber wie erhalten die Systeme B und C dieses Token?

Antwortinhalt:

Ich habe eine einmalige Anmeldung durchgeführt und bin auf ein Problem gestoßen: Es gibt beispielsweise drei Systeme A, B und C. Wenn keine Anmeldung vorhanden ist, wird zur Anmeldung zum S-System gesprungen. Wenn die Anmeldung vorhanden ist Erfolgreich, ein Token wird generiert und übertragen. Wenn Sie zurückkommen, wird das Token in Redis gespeichert. Aber wie erhalten die Systeme B und C dieses Token?

Nach Erhalt dieses token verwenden Sie curl oder header, um die Werte an die Schnittstellen der anderen beiden Systeme B bzw. C zu senden GET Oder POST empfängt den gesendeten token-Parameter und verarbeitet dann den Token-Wert. Speichern Sie beispielsweise den Token-Wert in Redis, Sitzung usw.

Sehr geehrte Damen und Herren, jetzt, wo Sie es in redis eingezahlt haben, können Sie B und C nicht mit redis verknüpfen und es dann direkt von redis

abheben?

Ich lehne die derzeit beste Antwort ab. Wenn beispielsweise Single Sign-On für die Anmeldung bei 100 Systemen verantwortlich ist, muss dann jedes System 99 Mal eine Anfrage stellen, nachdem sich ein Benutzer angemeldet hat? Was nennt man sonst noch Single Sign-On?

Andere Leute sagen, dass Token direkt von Redis gelesen werden. Wissen Sie, welcher Benutzer welchen Schlüssel liest?

Das sogenannte Single Sign-On bedeutet nicht, dass sich der Benutzer, wenn er sich bei A anmeldet, auch bei B und C anmelden kann, sondern dass er sich bei A, B anmelden kann, wenn er sich bei S anmeldet , und C.

Es sind also zwei Dinge erforderlich:

1. Das Cookie/die Sitzung des S-Systems selbst. Solange sich der Benutzer beim S-System anmeldet (ob er direkt auf S zugreift oder auf S zugreift, weil er sich bei A anmelden möchte), wird das Cookie/die Sitzung des Benutzer unter dem S-System werden nicht generiert. Es ist keine domänenübergreifende Verarbeitung erforderlich.
2. Der Benutzer kommt von System A. System S ermittelt, ob der Benutzer bei System S angemeldet ist. Wenn er nicht angemeldet ist, wird er zur Anmeldung aufgefordert. Nach der Anmeldung oder wenn er bereits angemeldet ist, Es wird ein eindeutiges Ticket generiert und der Benutzer wird angemeldet. Der Benutzer und das Ticket werden in der Datenbank gespeichert. Anschließend wird das Ticket über den Browser des Benutzers an System A zurückgegeben, und System S ermöglicht dem Browser des Benutzers, zu . Zu diesem Zeitpunkt erhält System A das Ticket und fordert intern die Verifizierungsschnittstelle von System S an. System S vergleicht das Ticket mit dem in der Datenbank, ermittelt die entsprechenden Benutzerinformationen und sendet sie an System A zurück. System A kennt dann den Benutzer Wer möchte sich anmelden? Wer ist das? http://AAA.com/login/callback?ticket=xxxxx

Es wird empfohlen, dass der Betreff einen Blick auf das CAS-Protokoll https://apereo.github.io/cas/... wirft.

Es gibt viele Gründe, Einwände gegen die angenommene Antwort zu erheben.

Zuallererst ist der Prozess der Ticketausstellung und -verifizierung falsch (dieses System benötigt normalerweise ein Hot-Backup mit zwei Maschinen, um einen Single-Point-Ausfall zu verhindern, oder es wird verteilt).
Wie andere bereits gesagt haben, können 100 Systeme bedeuten dieser Push 100? Was soll ich tun, wenn es zu einer Zeitüberschreitung oder ähnlichem kommt?
Wenn ein System abgemeldet ist, sollten auch andere Systeme abgemeldet werden?
Wenn die Berechtigungen geändert werden und nur Login A erlaubt ist und Login B nicht erlaubt ist , was soll ich tun?

Es gibt keine domänenübergreifenden Probleme.

1. Wenn Sie System a betreten, springen Sie zu System s.

2. Nachdem das s-System das Konto überprüft hat, lassen Sie den Browser mit dem Ticket (im URL-Parameter) zum a-System zurückspringen.

3. Zu diesem Zeitpunkt wurde das Ticket an das a-System übergeben

   Das System verwendet Curl und andere Methoden, um das Ticket im s-System zu überprüfen (Sie müssen auch den Schlüssel Ihres eigenen Systems mitbringen beweisen Sie, dass diese Überprüfung des A-Systems rechtmäßig ist) , wenn es sich um ein Autorisierungsticket handelt (selbst wenn Sie sich beim s-System anmelden, bedeutet dies nicht, dass Sie sich beim a-System anmelden können. Das s Das System ermittelt die erteilte Ticket-Anmeldeberechtigung) und lässt es dann eintreten, andernfalls springt es zurück zur System-Anmeldeschnittstelle.

Der Autor kann eine Java-Version des Open-Source-Single-Sign-On-Systems bereitstellen, um die spezifische Verwendung und den spezifischen Prozess kennenzulernen. Sie können auch ein Autorisierungssystem wie OAUTH2.0 entwickeln.

b und c bieten eine Schnittstelle zum Erhalten von Token. Aktualisieren Sie sie einfach nach dem Anmelden

Sie können erwägen, Cookies zum Speichern und Liefern zu verwenden

Nachdem die Master-Station die Anmeldung abgeschlossen hat, fügen Sie den domänenübergreifenden Code zur Seite hinzu, nachdem der Anmeldeserver zurückgesprungen ist, und senden Sie ihn gleichzeitig an die Slave-Station (oder andere Standorte). Der Code lautet wie folgt

<code><script src=xxxx.com?token=aaaaaa>
</code>

Auf diese Weise können Sie den Token in xxxx erhalten und die Verifizierung durchführen

Es wird empfohlen, UCenter oder OpenCenter zu verwenden, da beide problemlos Single Sign-On erreichen können

Was das Poster bedeutet, ist: 3 Systeme, domänenübergreifend, ich weiß nicht, wie ich die Sitzungs-ID speichern soll. Sie können UCenter oder PHP in Betracht ziehen, um P3P zu verwenden, um domänenübergreifend zu erreichen.

Im Allgemeinen wird das Token mithilfe eines Verschlüsselungsalgorithmus berechnet. Salt B und C müssen nur denselben Verschlüsselungsalgorithmus verwenden, um das Token zu überprüfen, wenn sie es erhalten.

Wird der Token nicht an die Systeme B und C zurückgesendet? Sie können eine direkte Verbindung zu Redis herstellen. Der Standardpunkt besteht darin, das Token in den Parameter oder Header einzufügen, um die spezielle Schnittstelle des S-Systems anzufordern.

,,,,,,,,,,