Opensso / OpenAM alternatywy

Integrujesz istniejące aplikacje, czy po prostu chcesz wspierać własne aplikacje?

Szukasz rzeczywistego SSO czy po prostu współdzielonych danych uwierzytelniających? SSO loguje się do jednej aplikacji, a posiadanie tego poświadczenia propaguje się do innej aplikacji (takie jak logowanie do Gmaila i automatyczne logowanie do Bloggera). Poświadczenie współdzielone polega na tym, że można używać tej samej nazwy logowania i hasła w różnych aplikacjach, ale samo poświadczenie nie jest automatycznie rozmnażane.

LDAP jest powszechnym systemem służącym do zarządzania współdzielonym poświadczeniem. Wiele systemów pozwala skierować swój sklep uwierzytelniania do istniejącego serwera LDAP.

Na przykład, jeśli masz kilka aplikacji wdrożonych w kontenerze Java EE, a także, powiedzmy, serwer poczty e-mail i klient poczty internetowej, wszystkie te różnorodne aplikacje mogą być kierowane na ten sam serwer LDAP, a użytkownicy będą mieli jeden login i hasło dla wszystkich różnych systemów, wszystkie napisane w różnych językach. Języki, wszystkie wdrożone na różnych maszynach. Jest to przykład użycia LDAP i prawie każdy system może sobie z tym poradzić po wyjęciu z pudełka. Glassfish i Tomcat mogą łatwo walidować na serwerze LDAP. Podobnie może Apache (Serwer Www), Postgres( baza danych), Postfix (e-mail), itp. itd.

Więc jeśli chcesz po prostu udostępnić poświadczenie, dostajesz to "za darmo", teraz, instalując serwer LDAP. LDAP to trochę inna bestia niż coś takiego jak DBMS, ale gdy już przestudiuj to trochę i "weź to", to naprawdę całkiem miłe. OpenLDAP jest popularnym serwerem LDAP, ale jestem częściowy do ApacheDS.

Sposobem na skonfigurowanie tego w kontenerze Java EE jest skonfigurowanie "Realm". GF i Tomcat mają LDAP realms z pudełka, wyobrażam sobie, że reszta zrobić. Ale nakrętka jest taka, że musisz użyć zabezpieczeń Java EE, aby wykorzystać Realm.

Widzisz, szczegół w środowisku Java EE polega na tym, że jest to aspekt kontenera, a nie aplikacji. Tak jak basen połączeniowy jest zasobem kontenera wykorzystywanym przez aplikację. Większość ludzi chce, aby Bezpieczeństwo było częścią ich aplikacji, w której czują, że mają nad nią większą kontrolę.

To wszystko dobrze i dobrze, dopóki nie zaczniesz otrzymywać kilka różnych aplikacji i każdy jest skonfigurowany inaczej i ma oddzielne listy użytkowników, i Polityki haseł, itp. itd.

LDAP może to naprawić, ponieważ skonfigurujesz je tak, aby używały tego samego magazynu poświadczeń.

The Realm fills that potrzeba na serwerze Java EE. Twoja aplikacja jest skonfigurowana do korzystania z serwera dostarczonego przez kontener. Jeśli masz kilka aplikacji i jeden serwer, wszystkie one mogą udostępniać poświadczenia w tym serwerze (niezależnie od typu serwera).

Realms może być czymkolwiek: bazującym na plikach, bazującym na db, LDAP itp. Realms również klastra, jeśli klastry kontenera (co może być przydatne).

Ciemna strona bezpieczeństwa Java EE, i dlaczego większość aplikacji tego unikają, ponieważ, ponownie, Realm jest częścią kontener, a nie aplikacja, może być trochę bezbożny w użyciu i być może nie oferuje funkcji, które lubisz w zakresie zarządzania użytkownikami, zasad haseł itp.

Ale dobrą stroną bezpieczeństwa Java EE jest to, że gdy już znajdziesz się pod jego parasolem, możesz łatwo wykorzystać poświadczenia w swoim kodzie. Osoba loguje się do witryny sieci web, a poświadczenie to może być tam używane w aplikacji internetowej lub automatycznie propagowane z powrotem do warstwy EJB (kiedykolwiek zdalnej warstwy EJB), a informacje są zawsze przydatne.

Możesz skierować swoje aplikacje internetowe na serwerze, EJB, swoje usługi internetowe. Wszystkie wykorzystują te same elementy.

Aby uzyskać najlepsze z obu światów, należy wykorzystać specyficzne dla kontenerów mechanizmy dostępu do bezpieczeństwa kontenerów. To druga ciemna strona bezpieczeństwa Java EE.

Rzeczy takie jak Realms i bezpośredni dostęp do zabezpieczeń kontenerów nie są przenośne w kontenerach. GF robi to inaczej niż Tomcat robi to inaczej niż WebLogic. Wszystko jest naprawdę blisko, ale różni się szczegółami, więc kod nie będzie bezproblemowo portowany.

Jasna strona jest dla aplikacji In house, większość ludzi po prostu wykorzystać kontener, który mają, umieścić rozsądną abstrakcję wokół kodu zależnego od kontenera, i nazwać go dzień, zauważając, że tak, będą musieli przenieść to, jeśli i kiedy przenieść do innego kontenera. Ale w praktyce. podobnie jak baza danych, po wybraniu platformy kontenerowej ludzie mają tendencję do ciasnego przytulania się i trzymania się to.

Wreszcie, Servlet 3.0 (w GF3 i Tomcat 7) standaryzuje więcej problemów z logowaniem programowym, aby uczynić je bardziej przenośnymi w kontenerach, ale podstawowe pojęcia są takie same.

Teraz, SSO.

SSO to inna bestia. Ale poza bramą zarówno GF, jak i Tomcat obsługują SSO dla aplikacji internetowych. Pozwala to zalogować się do jednej aplikacji internetowej i mieć możliwość łatwego dostępu do innych bez konieczności logowania się do nich. Ale SSO jest trochę ograniczone, ponieważ opiera się w większym stopniu na bezpieczeństwo kontenera i jego cykl życia, a nie bardziej elastyczny pod kontrolą aplikacji. Uwaga, nie tylko na Realms (to jest DANE), ale na rzeczywistym kontenerowym logowaniu, a nie na niestandardowym logowaniu programowym. Logowanie formularzy nie jest spektakularne, ale jest funkcjonalne i działa. Zaimplementuj Serwery, wdrażaj aplikacje do pojedynczej instancji Tomcat lub GF (lub klastra w GF 3.1), a otrzymasz SSO za darmo, więc jeśli to ważne, to naprawdę miłe. To usability jest w porządku dla aplikacji back office, ale może nie dla publicznego Internetu.

Jeśli chcesz bardziej wyrafinowane rozwiązanie SSO, musisz przyjrzeć się niestandardowym implementacjom. OpenSSO jest jednym z nich i opiera się na SAML i SAML web profile. Są jednak inne. Są też CAS, Atlassian Cloud, Kerberos i OAuth. Wszystkie używają innych protokołów niż SAML. Jeśli chcesz pozostać przy SAML możesz również spojrzeć na Shibboleth, lub nawet SimpleSAML (SimpleSAML jest serwerem PHP, który działa między innymi jako dostawca tożsamości SAML, ale nadal potrzebujesz dostawcy usług w swoich aplikacjach).

Niezależnie od wybranego protokołu, Proces jest zasadniczo taki sam (szczegóły tutaj -- Cross Domain Login-Jak zalogować się użytkownika automatycznie po przeniesieniu z jednej domeny do drugiej ).

Ale diabeł tkwi w szczegółach. I, chłopcze, są tam diabły.

Wszystkie te systemy są skomplikowane. SSO jest skomplikowane. Na przykład, teraz, gdy masz Single Sign On, a co z Single Sign Out? A co z pojedynczą przerwą? Co ze zmianami poświadczeń, gdy użytkownicy są zalogowani? A co z STS (Secure Token Service) dla Twoich usług internetowych? (STS oferuje podobny mechanizm delegowanego uwierzytelniania dla usług internetowych.)

SAML wprowadza cię w zupełnie nowe słownictwo i wiele konfiguracji. Nie jest łatwo odbierane, ponieważ dokumentacja nie jest gwiezdna i opiera się w dużej mierze na standardach dokumentów, które mówią o wyższym poziomie ogólne rzeczy, a nie do Ciebie i Twojej aplikacji konkretnie.

Jeśli naprawdę nie potrzebujesz SSO, prawdopodobnie będziesz zadowolony z czegoś takiego jak Centralny sklep LDAP i dalej.

Jako przykład, nasze aplikacje obsługują zarówno backend DB, jak i LDAP. Używają Glassfish i Java EE security. Całkowicie kontrolujemy wrażenia użytkownika. Wspieramy również SSO poprzez SAML( pisaliśmy własną tożsamość i dostawców usług), a my oboje dzieliliśmy poświadczenia za pośrednictwem LDAP i SSO w Javie i innych aplikacjach, przy użyciu naszego kodu i kodu stron trzecich. Dobrą stroną jest to, że wszystkie standardy są oparte. Ciemną stroną jest to, że standardy są przekazywane w języku angielskim, a język angielski podlega interpretacji.

Mówię to po prostu, aby powiedzieć, że można to zrobić. Pisałem również ad hoc, z tyłu implementacji serwetki SSO, zarówno tej samej domeny, jak i cross domeny (ta sama domena jest prosta z udostępnionym ciasteczkiem) za pomocą prostych filtrów serwletów. Hasło Zasady, odzyskiwanie hasła, timery keep alive, limit czasu wielu okien i zarządzanie sesjami( to jest hoot), role, uprawnienia itp. itd. Już to przerabiałem.

Ponadto, nie wspominając o Spring i Spring Security, które oferują to wszystko na wiosnę. Nie używałem (Nie jestem wiosenną osobą), ale ci ludzie wiedzą, co robią, więc warto się przyjrzeć.