Jednokrotne logowanie w wielu domenach [zamknięte]

110

Nasza firma ma skonfigurowanych wiele domen z jedną witryną hostowaną w każdej z nich. W tej chwili każda domena ma własne uwierzytelnianie, które odbywa się za pomocą plików cookie.

Gdy ktoś zalogowany w jednej domenie potrzebuje dostępu do czegokolwiek z drugiej, użytkownik musi zalogować się ponownie przy użyciu innych poświadczeń z innej witryny, znajdującej się w drugiej domenie.

Zastanawiałem się nad przejściem do pojedynczego logowania (SSO), aby wyeliminować ten problem. Byłbym wdzięczny za wszelkie pomysły, jak można to osiągnąć, ponieważ nie mam w tym zakresie żadnego doświadczenia.

Dzięki.

Edycja: Strony internetowe są połączeniem witryn internetowych (zewnętrznych) i intranetowych (używanych wewnętrznie w firmie).

authentication single-sign-on Pascal
źródło
To brzmi jak zadanie dla OpenID - ale zezwalaj tylko na identyfikatory z domeny logowania.
Neall
2
@Will To pytanie może nie dotyczyć tej witryny w sieci SE, ale jest zdecydowanie konstruktywne .
Binar Web
@BinarWeb Close Powody ewoluowały od 2008 roku. Wtedy był to najbardziej odpowiedni wybór.

Odpowiedzi:

91

Rozwiązanie SSO, które tutaj zaimplementowałem, działa w następujący sposób:

  1. Istnieje domena główna login.moja_domena.com ze skryptem master_login.php, który zarządza logowaniami.
  2. Każda domena klienta ma skrypt client_login.php
  3. Wszystkie domeny mają wspólną bazę danych sesji użytkownika.
  4. Gdy domena klienta wymaga zalogowania użytkownika, przekierowuje do domeny głównej (login.mydomain.com/master_login.php). Jeśli użytkownik nie zalogował się do administratora, żąda uwierzytelnienia od użytkownika (tj. Wyświetla stronę logowania). Po uwierzytelnieniu użytkownika tworzy sesję w bazie danych. Jeśli użytkownik jest już uwierzytelniony, wyszukuje jego identyfikator sesji w bazie danych.
  5. Domena główna powraca do domeny klienta (client.mydomain.com/client_login.php) przekazując identyfikator sesji.
  6. Domena klienta tworzy plik cookie przechowujący identyfikator sesji z serwera głównego. Klient może znaleźć zalogowanego użytkownika, wysyłając zapytanie do udostępnionej bazy danych za pomocą identyfikatora sesji.

Uwagi:

  • Identyfikator sesji to unikalny globalny identyfikator wygenerowany za pomocą algorytmu z RFC 4122
  • Master_login.php przekieruje tylko do domen znajdujących się na swojej białej liście
  • Master i klienci mogą znajdować się w różnych domenach najwyższego poziomu. Na przykład. klient1.abc.com, klient2.xyz.com, login.moja_domena.com
grom
źródło
To wygląda na dobre rozwiązanie grom. Co przechowujesz w bazie danych? Czy to (identyfikator_sesji, nazwa użytkownika, zakodowane_hasło)?
Jon M
3
Jak postępować w przypadku awarii domeny głównej login.moja_domena.com? Czy logowanie jest w tym momencie niemożliwe?
jjxtra
3
Czy ktoś utworzył jakieś przykłady kodu lub repozytorium github?
Joshua F. Rountree
To jest to, co określają prawie wszystkie protokoły SSO (np. SAML), ale z większym zabezpieczeniem przed atakami typu Replay i tak dalej.
cweiske
2
A jeśli nie udostępniają bazy danych użytkowników? Każda aplikacja internetowa partnera ma własną bazę użytkowników. Jak to napotykamy?
stuckedoverflow
33

Nie wymyślaj ponownie koła. Dostępnych jest wiele pakietów SSO międzydomenowych typu open source, takich jak JOSSO, OpenSSO, CAS, Shibboleth i inne. Jeśli korzystasz z technologii Microsoft (IIS, AD), możesz zamiast tego użyć Microsoft Federation (ADFS).

Markc
źródło
4
Oczywiście - widziałem zbyt wielu ludzi wdrażających własne rozwiązania bezpieczeństwa tylko po to, aby odkryć, że są podatni na powtórki, XSRF lub inne ataki
5
+1 Nie powinieneś [prawie] nigdy wymyślać na nowo koła bezpieczeństwa.
Mark E. Haase
13
OpenSSO nie żyje, a JOSSO i CAS to rozwiązania JAVA. Tylko do Twojej wiadomości
OneHoopyFrood
15

Jak różne są nazwy hostów?

Te hosty mogą udostępniać pliki cookie:

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

Ale te nie mogą:

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

W pierwszym przypadku możesz skorzystać z rozwiązania opartego na plikach cookie. Pomyśl o GUID i tabeli sesji bazy danych.

jason saldo
źródło
2

Jeśli korzystasz z usługi Active Directory, każda aplikacja może używać usługi AD do uwierzytelniania, logowanie może przebiegać bezproblemowo.

W przeciwnym razie, jeśli aplikacje mogą rozmawiać ze sobą za kulisami, możesz użyć sessionids i mieć jedną aplikację obsługującą generowanie identyfikatorów obsługującą wszystkie inne aplikacje.

Mikrofon
źródło
2
czy użytkownik nie musi nadal wpisywać nazwy użytkownika i hasła do domen domena1.com, domena2.com i domena3.com, kiedy po raz pierwszy trafia do tych witryn w tej sesji?
HaBo