it-swarm-eu.dev

Jak nastavit jednotné přihlášení pro více domén?

Nastavil jsem jednotné přihlášení pro dva z našich webů, které žijí ve stejné doméně: a.domain.com a b.domain.com

Udělal jsem to pomocí cookies, ale jsou závislé na doméně. A - jak je psáno ve Velké knize - nyní potřeba jednotného přihlášení na různých doménách zvýšila jeho ošklivou hlavu :) Jsem si 99% jistý, že můžu zapomenout na používání OpenId (nemají rádi externí služby) tady jsem je nemohl přimět, aby přijali reCaptcha )

Chtěl bych být schopen někoho identifikovat na různých webových stránkách (a.domena.com, b.anotherdomain.com atd.). Jaké jsou doporučené způsoby nastavení/správy jednotného přihlášení na více doménách? Máte nějaké konkrétní bezpečnostní obavy, o kterých bych měl vědět před vypracováním návrhu?

21
samy

Způsob, jakým bylo pro Stack Exchange Network implementováno jednotné přihlášení, je velmi zajímavý. Využívá HTML 5 Local Storage . V závislosti na podpoře prohlížeče, kterou požadujete, můžete použít podobnou metodu.

Další podrobnosti najdete v blogu stackoverflow Global Network Auto Login .

16
Mark Davidson

Pro OpenId nemusíte používat externí službu. Můžete interně hostit server OpenId a použít jej pro vaše SSO. To vám umožní využít otevřený zdrojový kód a veškerou práci, která se věnuje zabezpečení OpenId.

PS: OpenId lze použít k vytvoření jedinečné identity, kterou používá mnoho webů, ale v každé doméně se stále musíte ručně přihlásit.

5
Olivier Lalonde

Dva dobré protokoly pro to jsou OAuth (http://en.wikipedia.org/wiki/OAuth) a SAML. Můžete spustit svůj vlastní web „poskytovatele identity“ pomocí OpenID nebo jiné autentizace přístupy.

5
nealmcb

Možná vám s běžným souborem cookie domény pomůže nástroj ADFSv2 (bezplatné stažení pro systém Windows 2008R2). Zde je výňatek z web.config, který se nachází v C:\inetpub\adfs\ls, kterou budete muset nakonfigurovat, abyste dosáhli požadovaného účinku.

  <!--
    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
goodguys_activate

Spousta dobrých odpovědí.
Toto jsou některá dobrá řešení:

  • OpenId
  • OAuth
  • SAML
  • ADFS
  • Místní úložiště

I když si nemyslím, že by některé z nich byly opravdu triviální, aniž by se o nich něco dozvěděly.

Ještě lepší by bylo zavedení správného produktu web-SSO - i když se z vaší otázky zdá, že to není možnost (i když bych vás vyzval, abyste přehodnotili a pokusili se přesvědčit vaše vyšší-up).

Jedno docela zjednodušené řešení, které jsem viděl, a ve skutečnosti některé produkty web-SSO používají tento trik (všimněte si, že tento přístup nemusím nutně doporučit ve všech situacích, viz níže):
Mají třetí „autentizační“ doménu, která vydává „cookie identity“ (po ověření uživatele). Webové stránky v jiných doménách mohou podat jednoduchý POST požadavek na ověřovací doménu, který bude samozřejmě zahrnovat soubor cookie uživatele pro tuto doménu. Vrácená odpověď by v podstatě řekla původní doméně, zda je uživatel ověřen, a v případě potřeby jaká je jeho totožnost.
Pokud uživatel ještě není ověřen - byl přesměrován na stránku v ověřovací doméně, aby zadal své heslo atd.

I když je nastavení velmi jednoduché, uvědomte si, že v souvislosti s jeho skutečným zabezpečením existují určité problémy.
Například, jak je definováno, libovolný web může načíst vaši identitu. Spolehlivou webovou stránku lze také „oklamat“ úpravou vrácené odpovědi.
Samozřejmě nejjednodušší způsob řešení těchto problémů je - uhodli jste - SAML/OpenId/atd.

1
AviD

Právě jsem se zaregistroval, ale je překvapující, že jste nenašli odpověď jinde. Jak jste již zjistili, nemůžete předávat náhradní autentizační tokeny pomocí cookies.

Neuvedli jste žádné podrobnosti o tom, jak je implementováno ověřování pro váš aktuální web, ani o nástrojích, které máte k dispozici pro programování webů. Budu ale předpokládat, že mechanismus autentizace je psán v jazyce, který běží na webovém serveru a používá k sledování relace soubor cookie.

V takovém případě již máte kód na každé adrese URL, který vyžaduje ověření, aby bylo možné ověřit, zda byla relace ověřena, a poté provést příslušnou akci - buď vyřídit žádost nebo přesměrovat na přihlašovací stránku. Vše, co musíte udělat, je vypořádat se se scénářem, kdy neexistuje ověřená relace a v adrese URL je předána šifrovaná proměnná (tj. Jako GET). Hodnotu dešifrujete, zkontrolujete její platnost a v tomto okamžiku vytvoříte relaci. Poté na své přihlašovací stránce po úspěšném přihlášení přesměrujete připojením příslušného páru klíčů a hodnot k adrese URL.

To je stručný přehled - existují určitá vylepšení, o kterých musíte přemýšlet (např. Chcete, aby stejná data relací byla sdílena na všech webech, chcete znovu relaci pro různé relace zajistit, aby nevypršela platnost na straně serveru) a také musíte přemýšlet o tom, jak předcházíte opakovaným útokům (např. zahrnutí TTL do šifrovaného užitečného zatížení, včetně náhodně generované výzvy, ale pozor na použití IP adresy klienta).

Protože jste pouze šifrováním/dešifrováním na straně serveru, je symetrické šifrování dostatečné.

0
symcbean