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).


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

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).


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.


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.


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
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.