Obecnie oceniam ramy bezpieczeństwa oparte na Javie, jestem użytkownikiem Spring 3.0, więc wydawało się, że SpringSecurity będzie właściwym wyborem, ale bezpieczeństwo Spring wydaje się cierpieć z powodu nadmiernej złożoności, z pewnością nie wydaje się, że ułatwia wdrażanie zabezpieczeń, Shiro wydaje się być bardziej spójny i łatwiejszy do zrozumienia. Szukam list zalet i wad tych dwóch ram.
Odpowiedzi:
Ja też zgadzam się, że Spring Security wydaje się zbyt skomplikowane (dla mnie). Jasne, zrobili rzeczy, aby zmniejszyć złożoność, na przykład tworząc niestandardowe przestrzenie nazw XML w celu zmniejszenia ilości konfiguracji XML, ale dla mnie nie rozwiązują one mojego osobistego podstawowego problemu z Spring Security: jego nazwy i koncepcje są często ogólnie mylące mnie. Trudno to po prostu „pojąć”.
Jednak w momencie, gdy zaczynasz używać Shiro, po prostu „rozumiesz”. To, co było trudne do zrozumienia w świecie bezpieczeństwa, jest o wiele łatwiejsze do zrozumienia. Rzeczy, które są nieznośnie trudne w użyciu w JDK (np. Szyfry), są uproszczone do poziomu, który jest nie tylko znośny, ale często przyjemny w użyciu.
Na przykład, jak haszować + solić hasło i zakodować je w base64 w Javie lub Spring Security? Żadne z nich nie jest tak proste i intuicyjne jak rozwiązanie Shiro:
ByteSource salt = new SecureRandomNumberGenerator().nextBytes();
new Sha512Hash(password, salt).toBase64();
Nie potrzebujesz wspólnego kodeka ani niczego innego. Tylko słoik Shiro.
Jeśli chodzi o środowiska Spring, większość deweloperów Shiro używa Springa jako podstawowego środowiska aplikacji. Oznacza to, że wiosenna integracja Shiro jest znakomita i wszystko działa wyjątkowo dobrze. Możesz mieć pewność, że pisząc aplikację Spring, będziesz mieć wszechstronne zabezpieczenia.
Na przykład rozważ przykład konfiguracji Spring XML w innym poście w tym wątku. Oto jak zrobiłbyś (zasadniczo) to samo w Shiro:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd>
<bean id="shiroFilter" class="org.apache.shiro.spring.web.ShiroFilterFactoryBean">
<property name="securityManager" ref="securityManager"/>
<property name="loginUrl" value="/login.jsp"/>
<property name="successUrl" value="/home.jsp"/>
<property name="unauthorizedUrl" value="/unauthorized.jsp"/>
<property name="filterChainDefinitions">
<value>
/secure/** = authc
/** = anon
</value>
</property>
</bean>
<bean id="securityManager" class="org.apache.shiro.web.mgt.DefaultWebSecurityManager">
<property name="realm" ref="myRealm"/>
</bean>
<bean id="myRealm" class="...">
...
</bean>
Chociaż jest nieco bardziej rozwlekły niż w innym przykładzie Spring, łatwiej jest odczytać IMO.
Przekonasz się również, że użycie definicji łańcucha filtrów Shiro jest prawdopodobnie najłatwiejszym sposobem zdefiniowania ogólnych łańcuchów filtrów i internetowych reguł bezpieczeństwa! O wiele ładniejsze niż definiowanie ich w web.xml.
Wreszcie Shiro oferuje również ekstremalną „wtykalność”. Zobaczysz, że możesz skonfigurować i / lub wymienić prawie wszystko dzięki architekturze Shiro POJO / przyjaznej dla iniekcji. Shiro ustawia prawie wszystko na rozsądne wartości domyślne i możesz zmienić lub skonfigurować tylko to, czego potrzebujesz.
Pod koniec dnia myślę, że wybór jednego z tych dwóch bardziej zależy od twojego modelu mentalnego - który z nich ma więcej sensu i jest dla ciebie bardziej intuicyjny? Dla jednych będzie to Shiro, dla innych Spring Security. Shiro działa świetnie w wiosennych środowiskach, więc powiedziałbym, że wybierz na podstawie tego, który z nich lubisz bardziej i ma dla ciebie największy sens.
Więcej informacji na temat integracji Shiro Spring: http://shiro.apache.org/spring.html
Nie mam doświadczenia w używaniu Shiro i „częściowo” zgadzam się z tym, co powiedziałeś o Spring Security. Przed Spring Security 3.x konfiguracja Spring Security (lub Acegi) była bardzo uciążliwa. Prosta konfiguracja oparta na rolach zajmie co najmniej 140 wierszy tajemniczej konfiguracji XML ... Wiem o tym, ponieważ sam policzyłem wiersze. To było coś, co raz ustawiłeś i modlisz się, aby działało wiecznie bez ponownego dotykania konfiguracji, ponieważ możesz zapewnić, że zapomniałeś, co oznacza cała konfiguracja. :)
Dzięki Spring Security 3.x znacznie się poprawił. Wprowadza securityprzestrzeń nazw, która drastycznie skraca konfigurację ze 140 do ~ 30 linii. Oto przykład Spring Security 3.x jednego z moich projektów: -
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:security="http://www.springframework.org/schema/security" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security.xsd">
<security:http auto-config="true">
<security:form-login login-page="/index.do" authentication-failure-url="/index.do?login_error=1" default-target-url="/index.do"
always-use-default-target="true" />
<security:logout logout-success-url="/index.do" />
<security:intercept-url pattern="/secure/**" access="ROLE_ADMIN,ROLE_USER" />
<security:intercept-url pattern="/**" access="IS_AUTHENTICATED_ANONYMOUSLY" />
</security:http>
<bean id="customAuthenticationProvider" class="my.project.CustomAuthenticationProviderImpl">
...
</bean>
<security:authentication-manager>
<security:authentication-provider ref="customAuthenticationProvider" />
</security:authentication-manager>
</beans>
Piękno Spring Security 3.x polega na tym, że jest on niezwykle konfigurowalny, co przyczynia się do jednej z głównych wad: zbyt skomplikowanej, aby ją zrozumieć. Dokumentacja nie jest łatwa do odczytania, ponieważ tylko częściowo znam niektóre terminy używane przez Spring Security. Jednak opcje są dostępne, jeśli chcesz utworzyć niestandardową konfigurację lub kontrolować poziom szczegółowości zabezpieczeń. Albo możesz trzymać się powyższych <30 linii, aby przeprowadzić kontrolę bezpieczeństwa opartą na rolach.
To, co naprawdę podoba mi się w Spring Security, to to, że po skonfigurowaniu zabezpieczenia są płynnie integrowane z projektem. To tak, jakby rzeczywisty kod projektu nie wiedział o istnieniu zabezpieczenia ... i to dobrze, ponieważ pozwala mi łatwo odłączyć lub zaktualizować komponent bezpieczeństwa w przyszłości (np .: zmiana autoryzacji bazy danych na LDAP / CAS auth).
Używałem Spring Security (wersja 3.1) przez kilka miesięcy i byłem z niego całkiem zadowolony. Jest naprawdę potężny i ma bardzo fajną funkcję, zwłaszcza po wdrożeniu wszystkiego ręcznie, tak jak wcześniej! Było to jednak, tak jak gdzieś czytałem, coś w rodzaju czegoś, co ustawiłeś kiedyś blisko początku rozwoju aplikacji, a następnie modlisz się, aby działała do końca, ponieważ jeśli będziesz musiał to naprawić, prawdopodobnie zapomniałeś większości rzeczy, które musiałeś sparametryzować.
Ale potem pojawił się nowy projekt z bardziej złożonymi wymaganiami bezpieczeństwa. Krótko mówiąc, musieliśmy zaimplementować jakieś niestandardowe logowanie jednokrotne między kilkoma powiązanymi aplikacjami internetowymi.
Wiedziałem dokładnie, co chcę osiągnąć pod względem logiki HTTP, plików cookie, identyfikatorów sesji i innych rzeczy oraz co powinno się wydarzyć w jakiej kolejności, ale spędziłem większą część dnia zmagając się z interfejsami API Spring Security i nadal nie mogłem zrozumieć dokładnie określić, jaką klasę lub interfejs powinienem zaimplementować lub przesłonić i jak podłączyć je w kontekście. Całe API wydawało się naprawdę złożone i czasami nieco ezoteryczne. I chociaż dokument jest całkiem dobry dla ogólnych przypadków użycia, a nawet niektórych dostosowań, nie był wystarczająco głęboki, aby zaspokoić moje potrzeby.
Po przeczytaniu odpowiedzi tutaj i w innych miejscach w sieci odniosłem wrażenie, że Shiro będzie łatwiejszy do zrozumienia i dostosowania do moich potrzeb. Więc spróbowałem.
I cieszę się, że to zrobiłem, bo po całym dniu pracy udało mi się wystarczająco dużo dowiedzieć o API, aby nie tylko bezproblemowo skonfigurować podstawowy system uwierzytelniania i autoryzacji w mojej aplikacji Spring, ale także zaimplementować niestandardowe zachowanie SSO szukam. Musiałem tylko rozszerzyć 2 lub 3 klasy, a całość zajęła tylko około 25 linii konfiguracji XML w moim kontekście wiosennym.
Podsumowując, jeśli chodzi o łatwość użytkowania i krzywą uczenia się, Shiro jest naprawdę całkiem sympatyczny i myślę, że prawdopodobnie pójdę z nim w przyszłości, chyba że napotkam brak niektórych funkcji lub inny problem (którego nie jak dotąd).
TL; DR: Oba są potężne, ale Shiro jest znacznie łatwiejszy do nauczenia.