Jak działa logowanie jednokrotne z Active Directory, dzięki czemu użytkownicy są logowani w przejrzysty sposób w intranetowej aplikacji internetowej?

Powiedziano mi, że można stworzyć aplikację internetową, która nie wymaga logowania. Użytkownik loguje się do systemu Windows, który uwierzytelnia się za pomocą wyszukiwania Active Directory (LDAP). Następnie powinni móc przejść do mojej aplikacji internetowej i nigdy nie widzieć monitu o zalogowanie się. Ci klienci nazywają to jednokrotnym logowaniem (być może niepoprawnie i jest to część mojego zamieszania).

Ale z tego, co przeczytałem Single Sign On z dokumentów Tomcat, jest:

Zawór pojedynczego logowania jest wykorzystywany, gdy użytkownik chce umożliwić użytkownikom logowanie się do dowolnej aplikacji internetowej powiązanej z wirtualnym hostem , a następnie rozpoznanie ich tożsamości przez wszystkie inne aplikacje internetowe na tym samym hoście wirtualnym.

To jest dla mnie całkowicie jasne. Użytkownik musi się zalogować raz i może uzyskać dostęp do każdej aplikacji internetowej na instancji tomcat. Ale muszę w jakiś sposób pozwolić im się zalogować, nie podając żadnych danych uwierzytelniających na moim serwerze tomcat.

Aby to zadziałało, wyobrażam sobie:

• Użytkownik zgłasza prośbę o jakąś stronę
• Serwer nie widzi tokena sesji, a następnie prosi klienta o podanie poświadczeń.
• Przeglądarka klienta bez żadnej interwencji ze strony użytkownika podaje pewne poświadczenia dla serwera.
• Następnie, korzystając z poświadczeń podanych przez przeglądarkę klienta, wyszukuje w LDAP.

Widziałem kilka przykładów, które używają certyfikatów po stronie klienta ... szczególnie system DoD PKI, co ma dla mnie sens, ponieważ w takich przypadkach konfigurujesz Tomcat, aby żądał certyfikatów po stronie klienta , ale po prostu loguję się do okien, nie widzę, jak to będzie działać i jakie informacje przeglądarka przekaże na serwer itp. Czy do tego służy NTLM?

Przede wszystkim - w przypadku, gdy inni użytkownicy odwiedzą tę stronę - istnieją tylko niektóre metody uwierzytelniania, które pozwalają na bezzwłoczne logowanie jednokrotne. Są to NTLM i Kerberos . LDAP - z drugiej strony - nigdy nie zapewni szybkiego logowania jednokrotnego.

NTLM to tak naprawdę NTLMv1 i NTLMv2. Są one bardzo różne i NTLMv1 jest przestarzały z powodu poważnych problemów bezpieczeństwa. Należy unikać rozwiązań uwierzytelniania Java, które nie potrafią poprawnie zidentyfikować, czy obsługują NTLMv1 lub NTLMv2, ponieważ używają tylko słowa „NTLM” w swojej dokumentacji. Są szanse, że twórca wspomnianego rozwiązania bezpieczeństwa nie zna się, co jest tym bardziej powodem, aby szukać ucieczki przeciwpożarowej.

W przeciwieństwie do tradycyjnego przekonania, zarówno NTLMv1, jak i NTLMv2 są w pełni udokumentowane przez Microsoft, ale nadal znajdziesz rozwiązania, które twierdzą, że „przebudowano” protokół. Prawdą jest, że było to potrzebne przed dokumentowaniem przez Microsoft protokołów, które wierzę około roku 2006 lub 2007. W każdym razie NTLMv1 jest nie-nie. Nie ma nic złego w NTLMv2 per se, ale Microsoft wycofuje NTLM (w dowolnej formie) we wszystkich swoich produktach na rzecz uwierzytelniania Kerberos. NTLMv1 jest od dawna martwy, a NTLMv2 jest teraz używany tylko przez Microsoft w przypadkach, gdy nie jest dostępny kontroler domeny. Konkluzja: NTLM (w dowolnej formie) tak naprawdę nie jest drogą do przodu. W rzeczywistości powinniśmy pozdrowić Microsoft za przyjęcie podejścia opartego na standardach.

To pozostawia z Kerberos. Microsoft stworzył protokół do negocjacji i transportu informacji uwierzytelniających przez HTTP. Jest to znane w produktach Microsoft jako „ Zintegrowane uwierzytelnianie systemu Windows ”, ale zostało przybite jako oficjalny standard pod nazwą SPNEGO . Tego właśnie powinieneś szukać. SPNEGO obsługuje zarówno NTLMv2, jak i Kerberos jako podstawowy mechanizm uwierzytelniania, ale z powyższych powodów powinieneś celować w Kerberos, a nie NTLMv2.

Z powodzeniem zintegrowałem kilka aplikacji Tomcat (działających w systemie Linux / Solaris) z Active Directory przy użyciu projektu SPNEGO w SourceForge . Uważam, że jest to najprostsze podejście. To zapewnia natychmiastowe logowanie jednokrotne podobne do tego, co robi na przykład serwer Sharepoint. Tego najprawdopodobniej oczekują Twoi użytkownicy, mówiąc o „SSO”. Prawidłowe skonfigurowanie konfiguracji Kerberos, generowanie kluczy i konfigurowanie „fikcyjnych” kont w Active Directory może być kłopotliwe, ale po prawidłowym skonfigurowaniu działa jak urok.

Jedyną rzeczą, która mi się nie podoba w projekcie SPNEGO w SourceForge jest to, że nie rozumiem, jak często wykonuje uwierzytelnianie. Mam nieprzyjemne podejrzenia, że ​​robi to dla każdego wyświetlenia strony, a nie raz dla każdej sesji. Być może się mylę. W każdym razie: uwypukla to kolejną kwestię do rozważenia w rozwiązaniach SSO: nie chcesz implementować rozwiązania, które „spamuje” twojego dostawcę tożsamości (np. Active Directory) niepotrzebnymi żądaniami.

W środowisku Windows Active Directory logowanie jednokrotne oznacza, że ​​odwiedzanie wewnętrznej strony internetowej niesie za sobą uprawnienia logowania do systemu Windows i serwer internetowy może na nią działać. Jest to coś, do czego używa się NTLM, ale nowsze implementacje używają Kerberos.

Jeśli otworzysz witrynę Sharepoint Server, będzie ona wiedziała, kim jesteś bez potrzeby logowania nazwy użytkownika i hasła, ale działa to tylko w przypadku wewnętrznych stron internetowych w tej samej sieci, nie sądzę, aby miało to sens dla działania na publicznej stronie internetowej. (Nie wiem, czy masz na myśli „wirtualny host”, jak w vache Apache, czy jako serwer hostowany na zewnątrz).

Oto dokument Microsoft opisujący działanie uwierzytelniania Kerberos na serwerze WWW z uruchomionym IIS / ASP.Net: http://msdn.microsoft.com/en-us/library/ff647076.aspx

Wygląda na to, że można to zrobić za pomocą Apache / Tomcat / Java. Oto plik PDF opisujący tę implementację na uniwersytecie w Wielkiej Brytanii: http://gfivo.ncl.ac.uk/documents/UsingKerberosticketsfortrueSingleSignOn.pdf oraz projekt Codeplex: http://tomcatspnego.codeplex.com/ i Openfire dokumentacja dotycząca ogólnie pracy z Javą / Kerberos tutaj ( http://community.igniterealtime.org/docs/DOC-1060 ).

Wygląda na to, że opisujesz to, co Microsoft nazywa zintegrowanym uwierzytelnianiem systemu Windows.

Wygląda na to, że Tomcat obsługuje uwierzytelnianie systemu Windows na podstawie tego artykułu .

Na początek nie można uniknąć logowania. Jeśli chcesz zidentyfikować użytkowników, musisz mieć ich login. Zapomnij o NTLM, na ratunek przychodzi Kerberos - może zrobić wszystko w całkowicie przejrzysty sposób.

SingleSignOnValve nie jest tym, czego szukasz. Jeśli używasz Tomcat 7, można użyć SpnegoAuthenticator od razu, ale na 6 trzeba użyć tego .