Cookie-basiertes SSO

Question

Wie kann ich ein Cookie-basiertes Single Sign-On ohne einen SSO-Server implementieren? Ich möchte den eingeloggten Benutzer über mehrere Anwendungen hinweg nur mithilfe eines Cookies im Browser teilen.

In meinen Augen funktioniert das so:

• Benutzer loggt sich in eine Anwendung ein
• Die Anwendung überprüft die Anmeldeinformationen und legt dann ein Cookie im Browser an, das den Benutzernamen speichert (der mit einem privaten Schlüssel codiert sein könnte)
• Wenn der Benutzer eine andere Anwendung öffnet, sucht diese das Cookie und liest den Benutzernamen im Wert (unter Verwendung des Schlüssels zum Entschlüsseln der Zeichenfolge)

In dieser Lösung könnte ein Benutzer das Browser-Cookie eines anderen Benutzers einsehen und die codierte Zeichenfolge des Benutzernamens entnehmen. Dann könnte er sie seinem eigenen Cookie hinzufügen (nicht gut!).

Gibt es einen sicheren Weg, dies zu tun? Mit einer zeitgesteuerten Kontrolle oder etwas Ähnlichem?

Vielen Dank im Voraus.

Tschüss

P.S. Ich weiß, dass mein Englisch nicht sehr gut ist... Entschuldigung dafür!

Answer 1

Dies ist unmöglich. Cookies sind einzigartig für jede Domain, und eine Domain kann nicht die Cookies einer anderen Domain lesen.

Answer 2

Ich denke, die Antwort kommt ein wenig spät, aber vielleicht kann ich jemandem helfen.

Sie können ein Cookie / localStorage in einer Zwischendomäne haben, die mit der Startseite über ein iframe verbunden ist

1) Anmeldung Das Anmeldeformular in einer Ihrer Domänen hinterlegt das Identifizierungs-Token in einem Cookie auf sso.domain.com durch ein Ereignis (postMessage) 2) Verifikation Domäne1 und Domäne2 enthalten ein iframe, das auf sso.domain.com zeigt, das das Token liest und die Startseite benachrichtigt

Zur Vereinfachung der Entwicklung haben wir kürzlich ein Cross-Domain-SSO mit JWT unter https://github.com/Aralink/ssojwt veröffentlicht

Answer 3

Es gibt eine einfache Lösung, ohne einen SSO-Server zu verwenden, aber nicht mit einem gemeinsamen Cookie, da wir wissen, dass Cookies nicht zwischen Domains geteilt werden.

Wenn sich der Benutzer auf site-a.com authentifiziert, wird ein Cookie auf der Domain site-a.com gesetzt. Dann auf site-b.com verknüpfen Sie ein dynamisches JavaScript von site-a.com, das von serverseitigem Skript (php usw.) generiert wird und Zugriff auf das erstellte Cookie hat, und kopieren dann dasselbe Cookie auf site-b.com auf der Client-Seite mit js. Jetzt haben beide Websites dasselbe Cookie, ohne den Benutzer erneut einloggen zu müssen.

Sie können den Cookie-Wert verschlüsseln/kodieren, indem Sie eine Methode verwenden, die sowohl von site-a als auch von site-b entschlüsselt werden kann, so dass site-b in der Lage sein wird, seine Cookie-Kopie zu validieren. Verwenden Sie ein gemeinsames freigegebenes Geheimnis, ohne das es unmöglich wäre zu verschlüsseln oder zu entschlüsseln.

Sie sehen, dass beim ersten Seitenaufruf von site-b.com der Cookie nicht vorhanden ist, daher können Sie bei Bedarf einen Seitenneuladen durchführen, nachdem der Cookie gesetzt wurde.

Answer 4

Ich habe etwas Ähnliches gemacht. Es gibt eine PHP-Anwendung, bei der sich der Benutzer anmeldet, das System einen Webdienst kontaktiert und der Dienst dann die Anmeldeinformationen des Benutzers im Active Directory überprüft. Wenn der Benutzer authentifiziert ist, wird seine PHP-Sitzung in der Datenbank gespeichert. Eine andere Webanwendung kann die PHP-Sitzung aus den Cookies lesen und einen Webdienst in der PHP-Anwendung abfragen. Die PHP-Anwendung überprüft die Sitzung in der Datenbank und gibt die Benutzer-ID zurück. Auf diese Weise habe ich ein SSO mit SOA.

Verlassen Sie sich nicht auf die im Browser gespeicherte Benutzer-ID, das ist ein Sicherheitsfehler, verschlüsseln Sie zumindest die ID.

Die beste Lösung wäre, das Anmeldeformular und die Session-Speicherung in derselben Anwendung zu platzieren, damit diese Anwendung Dienste für andere Anwendungen bereitstellen kann.

Und verwenden Sie HTTPS für den Austausch von Informationen.

Die Cookies können nur gelesen werden, wenn sie zur selben Domäne gehören, zum Beispiel:

intranet.beispiel.com crm.beispiel.com beispiel.com/erp

Answer 5

Sie können auf Cookies über verschiedene Subdomains zugreifen, aber ich glaube nicht, dass die Verwendung von Browser-Cookies eine gute Lösung ist. Sie brauchen wirklich keinen "SSO-Server", um eine Single Sign-On zu implementieren. Es ist ziemlich einfach, ein Payload zu erstellen, das beide Anwendungen erkennen. Ich habe benutzerdefinierte SSO-Lösungen gesehen, die den Payload über XML über HTTPS übertragen.