Warum ist das Teilen einer Sitzung zum Implementieren von SSO nicht gut?

Question

Warum ist das Teilen der Sitzung zum Implementieren von SSO nicht gut? Ich lerne SSO-System.

über diese Szenen denkt: Angenommen, dass alle HTTP-Anforderungen an Business-Service Anmeldung erforderlich sind, muß der Business-Service die Anforderungen verifizieren Anmeldung oder nicht durch SSO-Dienst in CAS oder SAML zu fragen. Wenn es 10 Geschäftsdienste gibt und die Anforderung jedes Dienstes 1k req/s lautet, lautet die Anforderung des SSO-Dienstes 10k req/s. Es ist schwierig, sich vorzustellen, dass der SSO-Dienst sich halten kann.

SO, möglicherweise gibt es einen Cache-Mechanismus in den Business-Services, um Login-Token zu überprüfen. Beim Abmelden des Benutzers muss der SSO-Dienst jedoch die Überprüfungsinformationen entfernen, und die Geschäftsdienste müssen auch die Cache-Überprüfungsinformationen entfernen. Ich denke, das ist zu kompliziert. Der SSO-Dienst muss den Geschäftsdiensten mitteilen, dass sich einige Personen abgemeldet haben. Warum also nicht alle Service-Sharing die Login-Token verifizieren Info? Lassen Sie den SSO-Dienst schreiben und andere Unternehmen lesen. Es erinnert mich an die sharing the session to implement SSO. Und ich dachte, wenn ich die Login-Token teilen kann, verifiziere Info von wieder verteilten Cluster. Aber ich habe gehört, dass das Teilen nicht gut ist? Warum also?

Answer 1

Ob der SSO-Server so viele Anfragen verarbeiten kann, hängt von Ihrer Bereitstellung ab. Es gibt sehr große Bereitstellungen von CAS, die Hunderttausende von Anfragen behandeln. Es variiert.

Im Allgemeinen ist die SSO-Sitzung vollständig von Ihrer Anwendungssitzung getrennt. Nachdem Sie sich über SSO bei der Anwendung angemeldet haben, haben Sie eine Sitzung mit und für diese Anwendung eingerichtet, die so lange dauert, wie Sie sie für die letzte Zeit konfiguriert haben. Wenn es abläuft, entscheidet sich Ihre Anwendung möglicherweise erneut für die Authentifizierung bei Ihrem SSO-Server. Wenn der SSO-Server noch über eine SSO-Sitzung verfügt, werden einfach die entsprechenden Daten erneut ausgegeben und Ihre App erstellt die Sitzung erneut. Ist dies nicht der Fall, fordert es den Benutzer zur Eingabe von Anmeldeinformationen auf und wiederholt dieselben.

Sitzungsbedenken der Anwendung liegen ausschließlich bei Ihnen und der Anwendung. Der SSO-Server sollte sich niemals beteiligen. Wenn Ihre Anwendung Sitzungen teilen muss, weil sie geclustert sind, sollten Sie Sitzungen teilen. Niemand hat gesagt, dass es eine schlechte Idee ist. Im Allgemeinen möchten Sie jedoch sicherstellen, dass Ihre Anwendung so zustandslos wie möglich ist, da dies Cluster-Bereitstellungen vereinfacht.

Wenn Sie sich von Ihrer Anwendung abmelden, ist die App-Sitzung nicht mehr aktiv, die SSO-Sitzung ist jedoch möglicherweise noch vorhanden. Als Ergebnis gelangen Sie direkt zurück in die App, da Sie keine Anmeldeinformationen angeben müssen. Wenn Sie möchten, können Sie sich von der App UND Ihrem SSO-Server abmelden.

Wenn Sie alle anderen Anwendungen über SSO angemeldet haben und sich durch Abmelden abmelden möchten, wird dies als SLO bezeichnet. Ihr SSO-Server muss auf jede App, für die er ein Ticket erstellt hat, zugreifen und sich mit ihm in Verbindung setzen, um sich abzumelden. Oder Sie können die freigegebenen Sitzungen für alle Apps zerstören, sofern sie alle Teil derselben Suite sind.