it-swarm-eu.dev

Wie richte ich eine einmalige Anmeldung für mehrere Domänen ein?

Ich habe eine einmalige Anmeldung für zwei unserer Websites eingerichtet, die auf derselben Domain leben: a.domain.com und b.domain.com

Ich habe es durch Cookies gemacht, aber sie sind domänenabhängig. Und - wie es im Great Book geschrieben steht - jetzt hat die Notwendigkeit der einmaligen Anmeldung auf verschiedenen Domains ihren hässlichen Kopf erhoben :) Ich bin zu 99% sicher, dass ich die Verwendung von OpenId vergessen kann (sie mögen keine externen Dienste hier konnte ich sie nicht einmal dazu bringen zu akzeptieren reCaptcha )

Ich möchte jemanden auf verschiedenen Websites identifizieren können (a.domain.com, b.anotherdomain.com usw.). Was sind die empfohlenen Methoden zum Einrichten/Verwalten von Single Sign-On in mehreren Domänen? Gibt es spezielle Sicherheitsbedenken, die ich berücksichtigen sollte, bevor ich einen Vorschlag entwerfe?

21
samy

Die Art und Weise, wie Single Sign-On für das Stack Exchange Network implementiert wurde, ist sehr interessant. Es verwendet HTML 5 Local Storage . Abhängig von der von Ihnen benötigten Browserunterstützung können Sie möglicherweise eine ähnliche Methode verwenden.

Weitere Informationen finden Sie im Stackoverflow-Blogbeitrag Global Network Auto Login .

16
Mark Davidson

Sie müssen keinen externen Dienst für OpenId verwenden. Sie können einen OpenId-Server intern hosten und für Ihr SSO verwenden. Auf diese Weise können Sie Open Source-Code und die gesamte Arbeit nutzen, die für die Sicherheit von OpenId aufgewendet wurde.

PS: OpenId kann verwendet werden, um eine eindeutige Identität zu haben, die von vielen Sites verwendet wird. Sie müssen sich jedoch weiterhin "manuell" bei jeder Domain anmelden.

5
Olivier Lalonde

Zwei gute Protokolle hierfür sind OAuth (http://en.wikipedia.org/wiki/OAuth) und SAML. Sie können Ihre eigene "Identity Provider" -Site mit OpenID oder einer anderen Authentifizierung ausführen nähert sich.

5
nealmcb

Möglicherweise hilft Ihnen ADFSv2 (ein kostenloser Download für Windows 2008R2) mit dem allgemeinen Domain-Cookie. Hier ist ein Auszug aus der web.config in C:\inetpub\adfs\ls, die Sie konfigurieren müssen, um den gewünschten Effekt zu erzielen.

  <!--
    Common domain cookie. A common domain cookie stores a list of recently visited Claims Providers 
    (also called Identity Providers), as described in Section 4.3.1 of Profiles for the OASIS Security 
    Assertion Markup Language (SAML) V2.0. It is recommended that you enable common domain cookies by 
    including the <commonDomainCookie> element in the web.config file.

      1.The writer attribute of the <commonDomainCookie> element specifies the address of the writer 
      service that a Claims Provider uses to set the common domain cookie once it has authenticated a user.
      This address should be a valid URL.
      2.The reader attribute of the the <commonDomainCookie> element specifies the address of the reader
      service that a claims-aware service (also called a Service Provider) uses to get the list of Claims
      Providers that it should present to the user. This address should be a valid URL.

      The following configuration enables the use of common domain cookies and specifies writer and reader 
      services as described previously. 

      A common Domain Cookie is named "_saml_idp" in 4.3.1 http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
      Space delimited URI encoded

      RULES:
      Must be secure
      Must have path = /
      Must be leading period as in .domain.com 
      Can be session or persistant
      All providers should be configured similarly
      TODO-->
    <commonDomainCookie writer="" reader="" />
2

Viele gute Antworten hier.
Dies sind einige gute Lösungen:

  • OpenId
  • OAuth
  • SAML
  • ADFS
  • Lokaler Speicher

Obwohl ich nicht denke, dass diese wirklich trivial zu implementieren sind, ohne ein bisschen mehr über sie zu lernen.

Besser noch wäre es, ein richtiges Web-SSO-Produkt zu implementieren - obwohl es aus Ihrer Frage hervorgeht, dass dies keine Option ist (obwohl ich Sie dringend bitten würde, es zu überdenken und zu versuchen, Ihre Vorgesetzten zu überzeugen).

Eine ziemlich vereinfachte Lösung, die ich gesehen habe, und tatsächlich verwenden auch einige Web-SSO-Produkte diesen Trick (beachten Sie, dass ich diesen Ansatz nicht unbedingt in allen Situationen empfehle, siehe unten):
Haben Sie eine dritte "Authentifizierungs" -Domäne, die ein "Identitätscookie" ausgibt (nach der Authentifizierung des Benutzers). Websites auf anderen Domains können eine einfache POST - Anfrage an die Authentifizierungsdomäne senden, die natürlich das Cookie des Benutzers für diese Domain enthält . Die zurückgegebene Antwort würde der ursprünglichen Domain grundsätzlich mitteilen, ob der Benutzer authentifiziert ist und bei Bedarf seine Identität.
Wenn der Benutzer noch nicht authentifiziert ist, wird er auf eine Seite in der Authentifizierungsdomäne weitergeleitet, um sein Kennwort usw. zu übermitteln.

Dies ist zwar recht einfach einzurichten, es gibt jedoch einige Herausforderungen, wenn es darum geht, es tatsächlich sicher zu machen.
Wie definiert, kann beispielsweise die Website any Ihre Identität abrufen. Außerdem kann die vertrauende Website durch Ändern der zurückgegebenen Antwort "ausgetrickst" werden.
Der einfachste Weg, diese Probleme zu lösen, ist natürlich - Sie haben es erraten - SAML/OpenId/etc.

1
AviD

Ich habe mich gerade angemeldet, finde es aber überraschend, dass Sie anderswo keine Antwort gefunden haben. Wie Sie bereits herausgefunden haben, können Sie keine Ersatzauthentifizierungstoken mithilfe von Cookies übergeben.

Sie haben weder Details zur Implementierung der Authentifizierung für Ihre aktuelle Site noch zu den Tools angegeben, die Sie zum Programmieren der Sites zur Verfügung haben. Ich gehe jedoch davon aus, dass der Authentifizierungsmechanismus in einer Sprache geschrieben ist, die auf dem Webserver ausgeführt wird und ein Cookie verwendet, um die Sitzung zu verfolgen.

In diesem Fall haben Sie bereits Code für jede URL, für die eine Authentifizierung erforderlich ist, um zu überprüfen, ob die Sitzung authentifiziert wurde, und ergreifen Sie dann die entsprechende Aktion - entweder die Anforderung bearbeiten oder auf eine Anmeldeseite umleiten. Sie müssen sich lediglich mit dem Szenario befassen, in dem keine authentifizierte Sitzung vorhanden ist und in der URL eine verschlüsselte Variable übergeben wird (d. H. Als GET). Sie entschlüsseln den Wert, überprüfen seine Gültigkeit und erstellen an dieser Stelle eine Sitzung. Nach einer erfolgreichen Anmeldung leiten Sie auf Ihrer Anmeldeseite weiter und hängen das entsprechende Schlüssel/Wert-Paar an die URL an.

Das ist eine kurze Übersicht - es gibt einige Verbesserungen, über die Sie nachdenken müssen (z. B. möchten Sie, dass dieselben Sitzungsdaten für alle Sites freigegeben werden, möchten Sie die Sitzung für verschiedene Sitzungen neu binden, um sicherzustellen, dass sie nicht serverseitig abläuft). Außerdem müssen Sie darüber nachdenken, wie Sie Wiederholungsangriffe verhindern (z. B. Einschließen eines TTL in die verschlüsselte Nutzlast, einschließlich einer zufällig generierten Herausforderung, aber Vorsicht vor der Verwendung der Client-IP-Adresse).

Da Sie nur serverseitig verschlüsseln/entschlüsseln, ist eine symmetrische Verschlüsselung ausreichend.

0
symcbean