Transparent użytkownik w ciągu kilku stron (single sign-on + pojedynczy znak-off)

Question

Mam kilka miejsc w różnych dziedzinach: example.com, example.org, mail.example.com i passport.example.org. Wszystkie witryny mają wspólny wygląd i muszą mieć tę samą bazę użytkowników.

A w takim skrajnym przypadku nadal chcę wszystkich miejsc do przejrzysty (w miarę możliwości) sesje użytkownika akcji z następujących kluczowych właściwości:

1. single sign-on. Gdy użytkownik wpisze się w passport.example.org i wizyty każda inna strona - powinien on być traktowany jako zalogowany

   zalogowanych użytkowników dostać „Witam, $username„pozdrowienie w nagłówku witryny i innego menu nawigacji, wymieniając usługi mają dostęp. . Jeśli nie jest zalogowany, zamiast tego zamiast pozdrowienia pod numerem znajduje się link "Zaloguj się", wskazujący na passport.example.org/signon.

   Lista zaufanych domen jest znana, więc jest dość prosta implementacja z OpenID lub z niewielkim protokołem homebrewn. Kiedy użytkownik najpierw trafi na stronę , przekierowuję go do punktu końcowego o specjalnym uwierzytelnieniu pod numerem passport.example.org, , który następnie po cichu przekierowuje go z powrotem wraz z informacjami o tożsamości (lub "niezalogowanym"). W przypadku większości przeglądarek jest to całkowicie przezroczyste. Oczywiście, używam wartości nonce do walki z pętlami przekierowania.

2. Pojedyncze podpisanie. Kiedy użytkownik kliknie "wyloguj" w nagłówku dowolnej witryny następnym razem, gdy odwiedzi jakąkolwiek witrynę - powinien być postrzegany jako "niezalogowany".

   OpenID nie został do tego zaprojektowany. Mój obecny pomysł (mam już częściowo działającą implementację ) polega na wysyłaniu nie token tożsamości użytkownika, ale "globalny" token sesji i udostępnianie tabeli globalnych sesji (global_session_token ↔ user relacji) w DB.

3. Roboty i użytkownicy bezobsługowe obsługują. Witryny mają publiczne obszary, które powinny być dostępne dla użytkowników bez obsługi plików cookie.

   Z tego powodu przekierowanie, o którym wspomniałem (1), staje się problemem, ponieważ dla każdego pojedynczego żądania strony, skończę rzucać agent użytkownika do auth punktu końcowego iz powrotem. To nie tylko spowoduje zamieszanie w robotach, ale bardzo szybko spowoduje zanieczyszczenie sesji sesji sesji z porodem. I zdecydowanie nie chcę wyświetlać "hej, , jeśli nie masz włączonej obsługi plików cookie, odejdź!", Co byłoby wyjątkowo nieuprzejme i rozczarowujące. Chociaż do logowania potrzebuję obsługi plików cookie, chcę, aby użytkownicy mogli swobodnie czytać informacje o tym, do czego służą witryny i tak dalej - bez żadnych ograniczeń.

   I jednoznacznie nie chcę, aby umieszczał identyfikatory sesji w adresach URL z wyjątkiem niektórych przezroczystych przekierowań między domenami, o których już wspomniałem. Wierzę, że robienie tego jest problemem z ochroną i ogólnie rzecz biorąc, złą rzeczą.

   I tutaj prawie nie mam pomysłów.

Dobra, wiem, że to trudne, ale Google faktycznie robi to jakoś z (google.com, google.lot-of-gTLD, gmail.com i tak dalej), prawda? To powinno być możliwe .

Byłbym wdzięczny za pomysły na opisy protokołów (byłoby to najlepsze) lub linki do systemów (kod do czytania lub po prostu na żywo witryn do oglądania i uczenia się) już z powodzeniem wdrażając coś takiego.

Podsumowując: Kilka domen bez wspólnego katalogu głównego, współużytkowanej bazy użytkowników, pojedynczego logowania, pojedynczego podpisu, bez plików cookie wymaganych do przeglądania anonimowego.

Wszystkie witryny znajdują się w tej samej sieci (ale znajdują się na różnych serwerach) i częściowo udostępniają tę samą bazę danych PostgreSQL (w ramach różnych schematów tej samej bazy danych). Większość stron jest napisanych w Pythonie/Django, ale niektóre z nich używają PHP i Ruby on Rails. Chociaż myślę o czymś agnostycznym i ramowym, jestem wdzięczny za wskazanie jakichkolwiek implementacji. Nawet jeśli nie będę w stanie ich użyć, jeśli wpadnę na pomysł, jak to się robi, być może będę w stanie wymyślić coś podobnego.

Answer 1

Pozwolę sobie wyjaśnić nieco dalej. (Wszystkie adresy URL są fikcyjne!) Tak jak powiedziałem, odwiedzający podchodzi do http://www.yourwebpage.com i wskazuje, że chce się zalogować. Zostaje przekierowany na numer http://your.loginpage.org?return=http://www.yourwebpage.com/Authenticated, gdzie będzie musiał podać swoją nazwę użytkownika i hasło.
Gdy informacje o koncie są ważne, wróci do strony podanej w adresie URL logowania, ale z dodatkowym parametrem, który będzie używany jako identyfikator. W ten sposób przechodzi do http://www.yourwebpage.com/Authenticated?ID=SharedSecret, gdzie SharedSecret byłby tymczasowym identyfikatorem, ważnym przez 30 sekund lub mniej.
Po wywołaniu strony uwierzytelniającej strona wywoła metodę dzieloną między yourwebpage.com i loginpage.org w celu wyszukania informacji o koncie SharedSecret w celu pobrania bardziej stałego identyfikatora. Ten stały identyfikator jest przechowywany w sesji internetowej twojej witryny webwebpage.com i NIGDY nie powinien być pokazywany użytkownikowi.
Wspólną metodą może być wszystko. Jeśli oba serwery znajdują się na tym samym komputerze, mogą uzyskać dostęp do tej samej bazy danych. W przeciwnym razie mogą komunikować się z innym serwerem za pośrednictwem usług internetowych. Będzie to komunikacja między serwerami, więc nie ma znaczenia, czy użytkownik jest robotem, czy nie ma obsługi plików cookie. Ta część nie zostanie zauważona przez użytkownika.
Jedyne, co musisz zrobić, to sesja dla użytkownika. Zwykle użytkownicy otrzymają identyfikator sesji przechowywany w pliku cookie, ale może on również stanowić część adresu URL w ramach żądania GET. Trochę bezpieczniej jest mieć identyfikator sesji w żądaniu POST, dodając do formularza ukryte pole wejściowe.
Na szczęście kilka języków programowania obsługuje już sesje, więc nie musisz się martwić utrzymywaniem sesji i wysyłaniem identyfikatorów sesji. Technika jest jednak interesująca. Musisz mieć świadomość, że sesje powinny zawsze być tymczasowe, ponieważ istnieje ryzyko porwania identyfikatora sesji.
Jeśli masz do czynienia z wieloma witrynami w różnych domenach, najpierw musisz popracować nad komunikacją między serwerami. Najłatwiej byłoby pozwolić im korzystać z tej samej bazy danych, ale lepiej jest zbudować usługę sieciową wokół tej bazy danych, aby zapewnić dodatkową ochronę. Upewnij się, że ta usługa internetowa akceptuje tylko żądania z własnych domen, aby dodać jeszcze większą ochronę.
Po nawiązaniu połączenia serwer-serwer użytkownik będzie mógł przełączać się między domenami i dopóki przekazuje identyfikator sesji do nowej domeny, użytkownik zostanie zalogowany.Jeśli użytkownik używa plików cookie, nie jest bardzo prawdopodobne, że sesja zostanie utracona, co wymagałoby ponownego logowania. Bez plików cookie istnieje szansa, że ​​użytkownik będzie musiał zalogować się ponownie, aby uzyskać nowy plik cookie, jeśli identyfikator sesji zostanie utracony między przeglądaniem stron. (Na przykład użytkownik odwiedza Google, a następnie wraca do witryny. Za pomocą pliku cookie sesję można odczytać z pliku cookie. Bez pliku cookie sesja została utracona, ponieważ Google nie przekazuje identyfikatora sesji przekazanej dalej.
Należy pamiętać, że przekazywanie identyfikatorów sesji między różnymi domenami jest zagrożeniem bezpieczeństwa Identyfikator sesji może zostać przejęty, co umożliwia podszywanie się pod innego użytkownika, dlatego identyfikatory sesji powinny być krótkotrwałe i zaciemnione. Ale nawet jeśli haker uzyska dostęp do identyfikatora sesji, nadal nie będzie miał pełnego dostępu do samego konta. Nie będzie on w stanie przechwycić komunikacji między serwerami, więc nie będzie mógł uzyskać dostępu do bazy danych informacje o użytkowniku, chyba że przejdzie on bezpośrednio na stronę logowania:

Answer 2

Czy używasz ASP.NET? Jeśli tak, możesz chcieć rzucić okiem na właściwość enableCrossAppRedirects.

Answer 3

AFAIK, Google po prostu używa pliku cookie dla domeny "Google.com". Ale Google używa również OpenID, który pozwala na ogólny mechanizm logowania. Zasadniczo działa to poprzez przekierowanie do specjalnej strony logowania. Ta strona logowania wykryje, czy jesteś zalogowany, czy nie, a jeśli nie jesteś zalogowany, poprosi Cię o zalogowanie. W przeciwnym razie przekieruje Cię bezpośrednio na następną stronę.

Tak więc w twoim przypadku użytkownik otworzyłby stronę .example.com, a sesja dla tej aplikacji nie ma identyfikatora logowania. W ten sposób przekierowałby użytkownika do logon.example.biz, gdzie użytkownik będzie się logował. Za tą stroną byłaby również sesja, a ta sesja wskazywałaby, że użytkownik jest już zalogowany. (Lub nie, w takim przypadku użytkownik musi zaloguj się jako pierwszy.) Następnie przekierowuje użytkownika do strony .example.com?sessionid=something, gdzie ten identyfikator sesji byłby przechowywany w sesji w witrynie partepage.example.com. Wtedy ta sesja będzie również wiedzieć, że użytkownik zalogował się i dla użytkownika prawie wydawałby się przezroczysty.

W rzeczywistości użytkownik jest przekierowywany dwukrotnie.

Answer 4

Jeśli wszystkie aplikacje znajdują się w jednej domenie, nie jest to zbyt trudne, ponieważ do obsługi kontroli sesji można użyć pliku cookie na poziomie domeny. (Zarządzanie sesjami bez plików cookie jest trudne, ale można je wykonać, ale jest to trudne.)

Wskazano jednak niektóre witryny z domeny example.com, a niektóre z domeny example.org.

Odtwarzam trochę z moim westchnieniem google i innymi stronami ich orkut.com, wygląda na to, że po kliknięciu strony, która wymaga poświadczeń, przekierowuje cię do wspólnej strony logowania do konta, która następnie przekierowuje cię z powrotem do oryginalnej witryny, prawdopodobnie przekazując jakiś rodzaj tokena sesji w adresie URL. Z tego prawdopodobnie serwery orkut.com kontaktują się bezpośrednio z serwerami google.com, aby zweryfikować token i uzyskać wszelkie inne informacje o użytkowniku.

Więcej informacji na temat domeny najwyższego poziomu Cookies jako Reqeusted

Jeśli masz dwa miejsca, powiedzmy foo.example.com i bar.example.com, można ustawić ciasteczko specyficzną dla gospodarza, ale można również ustawić plik cookie dla domeny, która będzie być widocznym dla wszystkich hostów w domenie.

Więc foo.example.com można ustawić ciasteczko dla foo.example.com konkretnie, i to będzie widoczne tylko dla siebie, ale może również ustawić plik cookie dla domeny example.com, i gdy użytkownik przechodzi do bar.example.com będą również zobaczyć ten drugi plik cookie.

Jednakże, jeśli mają także miejsce, snafu.example.org, nie widzą tego poziomu ciastko domeny foo zestaw, ponieważ example.org i example.com są dwie zupełnie różne domeny.

Możesz użyć pliku cookie poziomu domeny, aby zachować informacje o sesji w witrynach w tej samej domenie.

Sposób ustawiania ciasteczek na poziomie domeny zależy od środowiska programistycznego (nie mam doświadczenia z szynami, przepraszam).

Answer 5

Dla tego rozwiązania nie ma potrzeby używania passporów t serwer.

signin

1. Logowanie
2. Tworzenie tokena z zaszyfrowanego identyfikatora sesji i innych informacji
3. Pokaż img z tokena od was wszystkich domen na ustawienie plików cookie w ITS.

Zatwierdzenie przez ciasteczka

1. Masz już ciasteczka na wszystkich domenach.

Sign out

1. Wyczyść cookies
2. Destroy sesja
3. Usuń identyfikator użytkownika relacja z ostatniego identyfikatora sesji w dB (myślę zapisać identyfikator sesji w tabeli użytkownika na wznoszące się sesję cookies)

Nie mogę wypróbować tego rozwiązania. Ale teraz mam ten sam problem co ty (SSO) i próbuję tego jutro.

Answer 6

Użyłem shibboleth, zarówno dla scenariuszy jednokrotnego logowania, jak i dla tożsamości federacyjnych, ale zakładam, że potrzebujesz bardziej prostych rozwiązań niż wymienione powyżej.

Answer 7

Wtyczka do radzenia sobie z wieloma domenami do tego celu byłaby niesamowita.

Chciałbym to zrobić, jedynym sposobem, jaki mogłem wymyślić, było zmusić użytkownika do pobrania paska narzędzi lub małej aplikacji do obsługi powietrza, która automatycznie obsłużyłaby logowanie.

Chciałbym poznać inny sposób, ponieważ te ciosy są nieodłączne.