Single Sign On über mehrere Domains hinweg [geschlossen]

110

Unser Unternehmen verfügt über mehrere Domains, auf denen jeweils eine Website gehostet wird. Zu diesem Zeitpunkt verfügt jede Domain über eine eigene Authentifizierung, die über Cookies erfolgt.

Wenn jemand, der bei einer Domain angemeldet ist, auf etwas von der anderen Domain zugreifen muss, muss sich der Benutzer erneut mit anderen Anmeldeinformationen auf der anderen Website der anderen Domain anmelden.

Ich dachte daran, auf Single Sign On (SSO) umzusteigen, damit dieser Ärger beseitigt werden kann. Ich würde mich über Ideen freuen, wie dies erreicht werden könnte, da ich diesbezüglich keine Erfahrung habe.

Vielen Dank.

Bearbeiten: Die Websites sind eine Mischung aus Internet- (extern) und Intranet-Websites (intern im Unternehmen verwendet).

authentication single-sign-on

— Pascal
quelle

Dies klingt nach einem Job für OpenID - lässt jedoch nur IDs von Ihrer Anmeldedomäne zu.

— Neall

2

@ Will Diese Frage ist möglicherweise nicht für diese Website im SE-Netzwerk, aber definitiv konstruktiv .

— Binar Web

@BinarWeb Seit 2008 haben sich enge Gründe entwickelt. Damals war dies die am besten geeignete Wahl.

91

Die SSO-Lösung, die ich hier implementiert habe, funktioniert wie folgt:

Es gibt eine Masterdomäne, login.mydomain.com mit dem Skript master_login.php, das die Anmeldungen verwaltet.
Jede Clientdomäne hat das Skript client_login.php
Alle Domänen verfügen über eine gemeinsam genutzte Benutzersitzungsdatenbank.
Wenn für die Clientdomäne der Benutzer angemeldet sein muss, wird zur Masterdomäne (login.mydomain.com/master_login.php) umgeleitet. Wenn sich der Benutzer nicht beim Master angemeldet hat, fordert er vom Benutzer eine Authentifizierung an (dh Anmeldeseite anzeigen). Nachdem der Benutzer authentifiziert wurde, wird eine Sitzung in einer Datenbank erstellt. Wenn der Benutzer bereits authentifiziert ist, wird seine Sitzungs-ID in der Datenbank nachgeschlagen.
Die Masterdomäne kehrt zur Clientdomäne (client.mydomain.com/client_login.php) zurück und übergibt die Sitzungs-ID.
Die Clientdomäne erstellt ein Cookie, in dem die Sitzungs-ID vom Master gespeichert wird. Der Client kann den angemeldeten Benutzer ermitteln, indem er die freigegebene Datenbank anhand der Sitzungs-ID abfragt.

Anmerkungen:

Die Sitzungs-ID ist eine eindeutige globale Kennung, die mit einem Algorithmus aus RFC 4122 generiert wird
Die Datei master_login.php leitet nur zu Domänen in ihrer Whitelist um
Der Master und die Clients können sich in verschiedenen Domänen der obersten Ebene befinden. Z.B. client1.abc.com, client2.xyz.com, login.mydomain.com

— grom
quelle

Das sieht nach einer guten Lösung aus. Was speichern Sie in der Datenbank? Ist es (session_id, username, hashed_password)?

— Jon M

3

Wie gehen Sie mit dem Fall um, in dem die Master-Domain login.mydomain.com ausfällt? Ist eine Anmeldung zu diesem Zeitpunkt nicht möglich?

— jjxtra

3

Hat irgendein Körper Codebeispiele oder ein Github-Repo produziert?

— Joshua F. Rountree

Dies ist, was fast alle SSO-Protokolle (z. B. SAML) spezifizieren, jedoch mit mehr Sicherheit gegen Wiederholungsangriffe und so weiter.

— Cweiske

2

Was ist, wenn sie keine Benutzerdatenbank gemeinsam nutzen? Jede Partner-Web-App hat ihre eigene Benutzerbasis. Wie begegnen wir dem?

— Stuckedoverflow

33

Erfinde das Rad nicht neu. Es gibt eine Reihe domänenübergreifender Open Source-SSO-Pakete wie JOSSO, OpenSSO, CAS, Shibboleth und andere. Wenn Sie Microsoft-Technologie (IIS, AD) verwenden, können Sie stattdessen Microsoft Federation (ADFS) verwenden.

— Markc
quelle

4

Absolut - Ich habe zu viele Leute gesehen, die ihre eigenen Sicherheitslösungen entwickelt haben, nur um festzustellen, dass sie für Wiederholungen, XSRF oder andere Angriffe anfällig sind

5

+1 Sie sollten das Sicherheitsrad [fast] nie neu erfinden.

— Mark E. Haase

13

OpenSSO ist tot und JOSSO und CAS sind JAVA-Lösungen. Nur ein FYI

— OneHoopyFrood

15

Wie unterschiedlich sind die Hostnamen?

Diese Hosts können Cookies teilen:

mail.xyz.com
www.xyz.com
logon.xyz.com

Aber diese können nicht:

abc.com
xyz.com
www.tre.com

Im ersteren Fall können Sie eine Cookie-basierte Lösung herausholen. Denken Sie an die GUID und eine Datenbanksitzungstabelle.

— Jason Saldo
quelle

2

Wenn Sie Active Directory verwenden, kann jede App AD zur Authentifizierung verwenden. Die Anmeldung kann dann nahtlos erfolgen.

Wenn die Anwendungen hinter den Kulissen miteinander kommunizieren können, können Sie andernfalls Sitzungs-IDs verwenden und eine App für die ID-Generierung verwenden, die alle Ihre anderen Anwendungen bedient.

— Mike
quelle

2

Muss der Benutzer nicht noch Benutzername und Passwort auf domain1.com und domain2.com und domain3.com eingeben, wenn er zum ersten Mal für diese Sitzung auf diesen Websites landet?

— HaBo