2010-05-08 13 views
5

Najlepiej coś, co dobrze integruje się z frontem Flex. Tak, ludzie z Spring Security mówią, że jest to możliwe, ale wszystkie przykłady wydają się korzystać ze starszych bibliotek znaczników jsp, co czyni je przykładami bezużytecznymi. Nie chcę spędzać miesiąca na konfigurowaniu i uczeniu się, jak używać narzędzia bezpieczeństwa. Chciałbym narzędzie, które obsługuje adnotacje (@RolesAllowed itp.), MINIMAL XML i funkcje "pamiętam-mnie" (nie oparte na plikach cookie).Jakie są alternatywy dla uwierzytelniania Java?

Apache Shiro wydaje się również obsługiwać Flex/Silverlight/Swing, ale chciałbym wiedzieć, czy istnieją inne alternatywy, które NIE są specyficzne dla kontenera.

+0

Jaki typ pamięci-mnie sugerujesz, kiedy mówisz, że nie chcesz, aby była oparta na plikach cookie? W ciągu jednej sesji możesz użyć parametrów w adresie URL, ale między sesjami nie wiem, w jaki sposób przechowywać poświadczenia bez ciasteczek (flash). –

+0

Czy obiekt SharedObject nie mógł tego zrobić? http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/net/SharedObject.html Nie wiem, czym byłaby logistyka, ale byłoby miło zrezygnować z zarządzania sesją kontenerów. używając czegoś, co NIE POTRZEBUJE kontenera (np. Shiro?) Chcę być w stanie wdrożyć do kontenerów J2EE bez obawy, że moja funkcja bezpieczeństwa/sesji będzie pękać za każdym razem, ale ja też nie chcę wydać 1/3 mojego czasu rozwoju ustawia takie zabezpieczenia. Czy nie jest to cel warty zachodu? – Manius

Odpowiedz

8

Okazało się, że Apache Shiro jest prostszym i łatwiejszym do nauczenia się rozwiązaniem niż bezpieczeństwo wiosenne. I nie jest głupia konfiguracja xml.

0

Nie widzę powodu, dla którego Flex powinien uwierzytelniać cokolwiek, po wszystkim, co jest stroną klienta. Co powstrzymuje kogoś przed dekompilacją flash/flex?

Dla większości osób Apache Shiro jest przesadą, a oni po prostu rzucają własną. Co nie jest najlepszym pomysłem, aby być szczerym. Przez lata widziałem wiele okropnych systemów uwierzytelniania. Pliki cookie mają na celu śledzenie sesji dla klienta, dlaczego warto skorzystać z czegokolwiek innego?

Edytuj: Użyj uwierzytelniania wiosennego.

+0

Myślę, że źle rozumiesz, nie chcę, żeby Flex sam się uwierzytelniał (a swf hacking jest właśnie powodem, dla którego szukam prawdziwych zabezpieczeń po stronie serwera).Tylko zaangażowanie polega na tym, że używane są zdalne wywoływanie (RemoteObject) za pośrednictwem Blaze lub Granite DS, a nie proste przesyłanie formularzy, co oznacza, że ​​przykłady tagów jsp nie są tak dobrymi przykładami. – Manius

+0

Sądzę również, że dokumenty Spring Security mówią o alternatywie trwałości opartej na plikach cookie, która jest bezpieczniejsza (zapominam, jak się nazywa, ale uważam, że używa bazy danych) i nie uważam, że pliki cookie są bardzo dobrze zintegrowane z aplikacją Flex. . I jeszcze jedno - uwierzytelnianie nie jest tak trudne (JAAS), ale autoryzacja wydaje się być bardziej problematyczna. – Manius

+2

@Crusader jesteś trochę zdezorientowany. Absolutnym wymogiem jest przekazanie identyfikatora sesji do serwera w celu utrzymania stanu sesji. Pogoda w tym stanie jest przechowywana przez Session Bean lub korzystanie z bazy danych jest nieistotne pod względem bezpieczeństwa. Jeśli ten identyfikator sesji zostanie ujawniony atakującemu przez xss lub sniffing, to konto zostanie przejęte. Właśnie dlatego OWASP A3: złamane uwierzytelnianie i zarządzanie sesją wymaga użycia HTTPS przez całą sesję. – rook

0

Spring Security to zdecydowanie najlepsze narzędzie.

BlazeDS nie jest magią. Ostatecznie jest to po prostu połączenie z serwerem za pośrednictwem protokołu HTTP. Aplikacja Blaze jest po prostu plikiem wojennym i ma tradycyjne adresy URL. Tak więc, aby chronić usługi, należy chronić adresy URL w plikach konfiguracyjnych web.xml/spring.

Zasadniczo przeczytaj dokumentację Spring Security/JAAS i zastąp jsps adresami URL swoich usług.

Spring Security obsługuje również role i autoryzację. Posiada także funkcję "pamiętam-ja", , ale, która bezwzględnie używa plików cookie. Nie możesz mieć funkcji "zapamiętaj mnie" bez plików cookie.

Jeśli chodzi o uwierzytelnianie, możliwe jest przekazanie tokena uwierzytelniania jako parametru żądania zamiast pliku cookie. Ale pliki cookie są zalecane i są o wiele łatwiejsze do uzyskania.

I na koniec bezpieczeństwo nie ma sensu bez korzystania z https. Musisz bezwzględnie używać https w swojej aplikacji, jeśli zależy Ci na bezpieczeństwie.

+3

Nie rozumiem, dlaczego wszyscy mówią, że Spring Security jest tak wspaniały (lub że Shiro jest "przesadą"), gdy Spring Security ma ogromną listę zależności i stromą krzywą uczenia się. Celem Shiro jest być "najłatwiejszym w użyciu", ma prawie żadnych zależności i piekła słoika, i bardzo mało konfiguracji. W przeciwieństwie do fetyszu Spring xml, po prostu nie rozumiem, jak ktoś mógłby powiedzieć, że Shiro jest przesadą. Jeśli coś Spring Security prawdopodobnie ma więcej funkcji, ale jest znacznie bardziej rozdęty. Wygląda na to, że te dwie są jedynymi alternatywami tam ... – Manius

Powiązane problemy