it-swarm.com.de

Wie implementiere ich domänenübergreifendes SSO mit automatischer Anmeldung ohne Browserumleitungen für nicht angemeldete Benutzer?

Ich muss eine SSO-Lösung mit den folgenden Anforderungen implementieren:

  1. Domänenübergreifend: Nehmen wir an, ich habe a.com, b.com Und sso.com. Wenn ich über a.com Angemeldet werde, sollte ich mich beim Besuch von b.com Nicht anmelden müssen.
  2. Zentralisiert: Nicht angemeldeter Benutzer, der unter a.com Auf "Anmelden" klickt, wird ein Anmeldebildschirm angezeigt, der auf sso.com Gehostet wird. Anmeldeinformationen werden von sso.com In einer Datenquelle überprüft, auf die nur zugegriffen werden kann.
  3. Automatische Anmeldung: Wenn sich der Benutzer bei a.com Angemeldet hat und anschließend b.com Aufruft, erfolgt dies sofort eingeloggt. Das heißt, auf b.com möchten wir anstelle eines "Login" -Links sofort ihren Benutzernamen usw. anzeigen - ohne auf etwas klicken zu müssen.
  4. Keine Weiterleitung für anonyme Benutzer: Die überwiegende Mehrheit meiner Benutzer wird die Websites ohne Konto verwenden. Wenn sie zum ersten Mal zu a.com Oder b.com Kommen, darf die gesamte Seite nicht schnell zu sso.com Und zurück umgeleitet werden, um zu überprüfen, ob sie angemeldet sind. Eine solche Weiterleitung wäre schlecht für SEO und Latenz.

Für die wenigen Benutzer, die sich bei a.com Und dann bei b.com (Oder umgekehrt) angemeldet haben, ist eine Weiterleitung akzeptabel.

Es gibt viele Beispiele für SSO im Web, insbesondere für OAuth2, OpenID Connect und CAS, aber ich konnte kein Rezept für diese spezifischen Anforderungen finden. Das nächstgelegene ist das Stackoverflow-SSO-Handbuch ( hier ), aber es gibt einige zusätzliche Anforderungen, die ich nicht habe (z. B. sollte die Anmeldung weiterhin funktionieren, wenn der SSO-Server nicht verfügbar ist).

10
Jan Żankowski

Es scheint mir, dass dieses OpenID Connect-Schema dies tun sollte. Beachten Sie jedoch, dass ich kein Sicherheitsexperte bin. Verwenden Sie es daher nicht ohne weitere Bestätigung.

  1. Der Benutzer ist nicht bei a.com, b.com, sso.com Abgemeldet.
  2. Der Benutzer geht zu a.com Und klickt auf "Login".
  3. Weiterleiten an sso.com Mit der Rückgabe-URL auf a.com Als Parameter.
  4. Der Benutzer gibt gültige Anmeldeinformationen an. sso.com Akzeptiert sie und leitet sie mit dem Autorisierungscode als Parameter an a.com Weiter. Es gibt auch ein SSO-Sitzungscookie für sso.com In der Weiterleitungsantwort.
  5. Browser folgt der Umleitung, fragt a.com. Der Server a.com Sendet den Autorisierungscode an sso.com Im Backend, empfängt das Zugriffstoken und das ID-Token und setzt das Sitzungscookie auf a.com. Der Benutzer ist jetzt unter a.com Angemeldet.
  6. Benutzer geht zu b.com.
  7. Javascript auf b.com Führt einen stillen CORS AJAX Aufruf von sso.com An einen benutzerdefinierten Endpunkt (z. B. sso.com/has-sso-session) Aus. Der Endpunkt antwortet im Wesentlichen mit true/false basierend auf dem Vorhandensein eines SSO-Cookies in der Anforderung.
  8. Wenn die Antwort lautet:
    • true, Javascript leitet den Browser zu sso.com um, wobei die Rückgabe-URL auf b.com als Parameter lautet. Dies löst eine regelmäßige OpenID Connect-Authentifizierung aus, die automatisch erfolgt, da der Benutzer über ein SSO-Cookie verfügt. Am Ende sendet der Server b.com Den Autorisierungscode an sso.com Im Backend, empfängt das Zugriffstoken und das ID-Token und setzt das Sitzungscookie auf b.com. Der Benutzer ist jetzt unter b.com Angemeldet.
    • false, Javascript setzt ein SSO check failed - Sitzungscookie auf b.com. Dies verhindert weitere Überprüfungen beim Durchsuchen von b.com, Es sei denn, der Benutzer klickt auf "Anmelden".
5
Jan Żankowski

Die einfachste und einzige Möglichkeit, SSO ohne Umleitung auszuführen, besteht darin, dass alle Ihre Anwendungen auf Subdomänen ausgeführt werden (a.site.com, b.site.com). Subdomains können Cookies auf Domain-Ebene freigeben, sodass Ihre Anwendung das Anmelde-Cookie direkt von der ersten Anfrage an erhält.

Wenn Sie möchten, dass sich Ihre Anwendungen auf mehreren nicht verwandten primären Domänen befinden (a.com, b.com) Das Beste, was Sie tun können, ist ein JavaScript, das beim Laden der Seite eine domänenübergreifende Anforderung an den SSO-Dienst sendet, um zu entscheiden, ob ein Zugriffstoken abgerufen werden soll. Dies hat keine Auswirkungen auf die Suchmaschinenoptimierung, da Spider kein JavaScript ausführen und auch keine Latenz für anonyme Benutzer hinzufügen, da beim ersten Laden der Seite durch nicht angemeldete Benutzer die anon-Version der Seite gerendert wird.

2
Lie Ryan