2008-09-04 16 views
95

Unser Unternehmen verfügt über mehrere Domains mit einer Website, die auf jeder der Domains gehostet wird. Zu diesem Zeitpunkt verfügt jede Domain über eine eigene Authentifizierung, die über Cookies erfolgt.Single Sign On für mehrere Domains

Wenn sich jemand, der sich an einer Domäne anmeldet, von dem anderen aus zugreifen muss, muss er sich mit anderen Anmeldeinformationen auf der anderen Website, die sich auf der anderen Domäne befindet, erneut anmelden.

Ich dachte daran, in Richtung Single-Sign-On (SSO) zu gehen, 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.

Danke.

Edit: Die Webseiten sind Mischung aus Internet (extern) und Intranet (intern verwendet innerhalb der Gesellschaft) verantwortlich.

+0

Das klingt wie ein Job für [OpenID] (http://openid.net/) - aber nur IDs aus Ihrer Anmeldedomäne zulassen. – Neall

Antwort

2

Wenn Sie Active Directory verwenden, könnte jede App AD für die Authentifizierung verwenden, die Anmeldung könnte dann nahtlos erfolgen.

Wenn die Anwendungen im Hintergrund miteinander kommunizieren können, können Sie sessionids verwenden und eine Anwendung verwenden, die die ID-Generierung für alle anderen Anwendungen übernimmt.

+0

ist der Benutzer nicht immer 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

14

Wie unterschiedlich sind die Hostnamen?

können diese Hosts teilen Cookies:

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

aber diese können nicht:

  • abc.com
  • xyz.com
  • www.tre.com

Im ersteren Fall, dass Sie ein Cookie-basierte Lösung schlagen kann. Think GUID und eine Datenbanksitzungstabelle.

76

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

  1. Es gibt eine Hauptdomäne, login.mydomain.com mit dem Skript master_login.php, die die Anmeldungen verwaltet.
  2. Jede Clientdomäne hat das Skript client_login.php
  3. Alle Domänen verfügen über eine gemeinsame Benutzersitzungsdatenbank.
  4. Wenn die Clientdomäne erfordert, dass der Benutzer angemeldet ist, wird in die Masterdomäne (login.mydomain.com/master_login.php) umgeleitet. Wenn der Benutzer sich nicht beim Master angemeldet hat, fordert er eine Authentifizierung vom Benutzer an (z. B. Anmeldeseite anzeigen). Nachdem der Benutzer authentifiziert wurde, erstellt er eine Sitzung in einer Datenbank. Wenn der Benutzer bereits authentifiziert ist, sucht er seine Sitzungs-ID in der Datenbank.
  5. Die Hauptdomäne kehrt zur Clientdomäne (client.mydomain.com/client_login.php) zurück und übergibt die Sitzungs-ID.
  6. Die Client-Domäne erstellt ein Cookie, das die Sitzungs-ID vom Master speichert. Der Client kann den angemeldeten Benutzer herausfinden, indem er die freigegebene Datenbank mit der Sitzungs-ID abfragt.

Hinweise:

  • Die Session-ID ist eine einzigartige globale Kennung erzeugt mit Algorithmus von RFC 4122
  • Die master_login.php nur Domänen in seiner weißen Liste
  • Der Master und Clients umleitet kann in verschiedenen Top-Level-Domains sein. Z.B. client1.abc.com, client2.xyz.com, login.mydomain.com
+0

Das sieht nach einer guten Lösung aus. Was speicherst du in der Datenbank? Ist es (Sitzungs-ID, Benutzername, Hash-Passwort)? –

+1

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

+3

Jeder Körper produzierte irgendwelche Codebeispiele oder ein GitHub Repo? –

30

Erfinden Sie das Rad nicht neu. Es gibt eine Reihe von Open-Source-domainübergreifenden SSO-Paketen wie JOSSO, OpenSSO, CAS, Shibboleth und anderen. Wenn Sie Microsoft-Technologie durchgängig verwenden (IIS, AD), können Sie stattdessen Microsoft Federation (ADFS) verwenden.

+2

Absolut - Ich habe zu viele Leute gesehen, die ihre eigenen Sicherheitslösungen rollen lassen, nur um festzustellen, dass sie anfällig für Replay, XSRF oder andere Angriffe sind. –

+3

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

+6

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

Verwandte Themen