Logowanie do domeny krzyżowej - Automatyczne logowanie użytkownika po przeniesieniu z jednej domeny do innej

Question

Oferujemy szereg usług online. Jesteśmy zobowiązani do opracowania systemu, który zapewnia szybkie/proste doświadczenie dla użytkowników, jeśli są one przekazywane z jednej usługi (na domain1.com) do innej usługi (na domain2.com).

Czy istnieje bezpieczny sposób automatycznego logowania użytkownika automatycznie po jego przeniesieniu do nowej usługi?

Krzyknij na mnie, jeśli poniższe rozwiązanie jest całkowicie niezabezpieczone/błędne.

Rozważaliśmy system podobny do tego, który zapewnia wiele usług online służących do odzyskiwania haseł - są one wysyłane e-mailem do łącza z unikatowym hashem, który wygasa, co pozwala im zmienić hasło.

Numer domain1.com wygeneruje unikatowy skrót i zapisze go w bazie danych z hashem powiązanym z użytkownikiem wraz z datą utraty ważności datetime.

Użytkownik zostanie przeniesiony do domain2.com/auto/?hash=d41d8cd98f00b204e9800998ecf8427e

domain2.com będzie następny złożyć wniosek do domain1.com z mieszania, aby uzyskać informacje na temat użytkownika. domain1.com następnie usunąłby hash z bazy danych. domain2.com logowałby użytkownika i ustawił plik cookie itp.

Czy coś na podstawie OpenID lub OAuth może osiągnąć takie same wyniki?

Answer 1

Jeśli ktoś byłby w stanie zagrać człowieka w środku i złapać ten skrót, czy byliby w stanie ukraść transfer domeny? Oczywiście musi zostać wygenerowany i wysłany do klienta przed ich potrzebą użycia. Powiedz na przykład:

Gram człowieka w środku szpiegując Jacka. Jack uzyskuje dostęp do domain1.com, co powoduje przygotowanie i przesłanie hasha, aby po uzyskaniu dostępu do domain2.com mógł wysłać ten skrót jako uwierzytelnienie. Gdy wchodzi do domain1.com, jego prośba przychodzi przeze mnie, zwracasz stronę, chwytam hasz i pozwalam mu kontynuować. Uzyskuję dostęp do domain2.com przy użyciu skrótu, teraz pozwól mi wejść do domain2.com i usunąłem skrót. Nie jest mądrzejszy, dopóki nie spróbuje zalogować się na numer domain2.com i zostanie poinformowany, że jego poświadczenia nie są już ważne.

Jak sobie z tym poradzić?

Answer 2

To jest dobre rozwiązanie. Oto dwa punkty do rozważenia:

Używasz terminu "hash", ale nie jest jasne, jakie dane będziesz mieszać. Zamiast tego użyj "nonce": dużej (128-bitowej) liczby wygenerowanej przez RNG o jakości kryptograficznej.

Nie określono tego, ale komunikacja między użytkownikiem i obiema domenami oraz między domenami musi być bezpieczna. Użyj protokołu SSL do uwierzytelnienia serwerów i zachowania poufności.

Answer 3

Pojedyncze logowanie (SSO) jest koncepcyjnie dość proste.

• Użytkownik hits domain1.com.
• domain1.com widzi, że nie ma pliku cookie sesji.
• domain1.com przekierowuje do sso.com
• sso.com prezentuje stronę logowania i podjąć poświadczenia
• sso.com zestawy cookie sesji dla użytkownika
• sso.com następnie przekierowuje z powrotem do domain1 do specjalnego adresu URL (jak domain1.com/ssologin)
• ssologin URL zawiera parametr, który jest zasadniczo "podpisany" przez sso.com. Może to być tak proste, jak podstawa 64 szyfrowania identyfikatora logowania za pomocą wspólnego tajnego klucza.
• domain1.com pobiera zaszyfrowany token, odszyfrowuje go, używa nowego identyfikatora logowania, aby zalogować użytkownika.
• domain1 ustala plik cookie sesji dla użytkownika.

Teraz kolejny przypadek.

• użytkownika uderza domain2.com, co następuje domain1 i przekierowuje do sso.com
• sso.com już cookie dla użytkownika, więc nie stwarza stronę logowania
• sso.com przekierowuje z powrotem do domain2.com z zaszyfrowanej informacji
• domain2.com loguje użytkownika.

Oto podstawy tego działania. Możesz uczynić go bardziej wytrzymałym, bogatszym w funkcje (na przykład jest to SSOn, ale nie SSOff, użytkownik może się wylogować z domain1, ale nadal być zalogowany do domain2). Do podpisywania poświadczeń można używać kluczy publicznych, można żądać przekazania większej ilości informacji (takich jak uprawnienia do autoryzacji itp.) Z serwera jednokrotnego logowania. Możesz mieć bardziej intymną integrację, taką jak domeny rutynowo sprawdzające, czy użytkownik nadal ma prawa z serwera jednokrotnego logowania.

Ale uzgadnianie ciastek poprzez przeglądarkę za pomocą przekierowań jest kluczową podstawą, na której opierają się wszystkie te rozwiązania SSO.

Answer 4

Co z SEO? Wygląda na to, że każde żądanie przed pomyślnym zalogowaniem zostanie przekierowane do innej domeny iz powrotem. Powiedziałbym, że to bardzo brzydkie. Jakie nagłówki należy przesyłać? 301 do SSO, a następnie z powrotem 301 do oryginalnej strony? Więc bot wyszukiwania jest "wymagany", aby dwukrotnie zmienić jego indeks dla tej strony?

Answer 5

Nie byłoby sensu używanie protokołu SSL do logowania w wielu domenach, chyba że korzystasz z protokołu SSL przez całą sesję. Równie łatwo można ukraść plik cookie sesji, jak używać hasha w adresie URL. Jaki jest sens ukrywania hasha w SSL, jeśli pozostała część sesji jest niepewna.

Metoda podana na górze to metoda standardowa. Niezależnie od tego, czy zdecydujesz się korzystać z bezpiecznych protokołów, to zupełnie inna sprawa, ale bezcelowe byłoby tylko szyfrowanie części sesji.