Shiro vs. SpringSecurity [zamknięte]


132

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:


118

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


Przeczytałem to wszystko, zanim zacząłem używać shiro. Adnotacje Shiro wydają się mieć pewne problemy na wiosnę. Informacje o tym, jak to rozwiązać, są bardzo złe i są różne posty w stackoverflow (1 lub 2 opublikowane przeze mnie), na które przez większość czasu nie znaleziono odpowiedzi. Poważnie myślałem, że powinienem pójść na wiosenną ochronę, mimo że mówiło to o komplikacji, z tym jestem pewien, że mogę mieć ludzi, którzy wskażą mi właściwy kierunek.
czarny sensei

@blacksensei czy rozwiązałeś problemy, o których wspomniałeś? Pozostajesz z Shiro lub przerzuciłeś się na Spring Security?
Alexander Suraphel

Cześć @AlexanderSuraphel Nie przeniosłem się do Springa dla tego projektu. Kolega aktywnie z niego korzysta. Planuję to przetestować w ramach projektu typu spring boot. U mnie to działa dobrze. Wszystkie inne projekty przeniosę. To takie proste
czarny sensei

Ok, zdecydowałem się wypróbować Shiro przy następnym projekcie !!
Eric Wang

32

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).


Czy chciałbyś coś powiedzieć o tym, kiedy dobrze jest przejść od zabezpieczeń opartych na kontenerach do alternatyw, takich jak shiro lub inne? Zobacz bardziej ukierunkowane pytanie tutaj: stackoverflow.com/questions/7782720/…
Rajat Gupta

10
Wypróbowałem zarówno shiro, jak i zabezpieczenia wiosenne i osobiście uważam, że shiro jest dość łatwe do zrozumienia, ponieważ bezpieczeństwo wiosenne wydaje się złożone. Jeszcze nie wymyśliłem, jak skonfigurować uprawnienia, które mogę przypisać do ról / grup / użytkowników w wiosennych zabezpieczeniach - (myślę, że ACL może być rozwiązaniem). Z shiro było to całkiem proste. Nie jestem ekspertem od zabezpieczeń wiosennych ani shiro, to tylko moje osobiste doświadczenie jako użytkownika obu.
Sudhir N

@sudhir, czy napotkałeś jakieś wąskie gardła w konfigurowalności Shiro?
Alexander Suraphel

To działało we wszystkich naszych przypadkach użytkowników, myślę, że można go dostosować do większości sytuacji. Jaki jest Twój przypadek?
Sudhir N

21

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.


Pierre, dzięki za wkład. Potrzebuję też sso. Nie sądzę, abyś mógł pokazać kilka przykładów zajęć, które musiałeś ujawnić.
KingAndrew

@KingAndrew: w kilku słowach zaimplementowałem własne AuthorizingRealm, AuthenticationToken i AuthenticationFilter. I wszystkie niezbędne filtry i hydraulika. Ale to, co robię, nie jest „normalne”, opiera się na tokenach przechowywanych w bazie danych, które są wspólne dla obu aplikacji. Więc nie używam oddzielnego serwera SSO.
Pierre Henry
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.