В даний час я оцінюю рамки безпеки на базі Java, я користувач Spring 3.0, тому здавалося, що SpringSecurity був би правильним вибором, але схоже, що безпека Spring страждає від надмірної складності, але, звичайно, не здається, що це полегшує безпеку для впровадження, Широ, здається, набагато злагодженіший і легший для розуміння. Я шукаю списки плюсів і мінусів між цими двома рамками.
Відповіді:
Я теж згоден, що Spring Security відчуває себе занадто складною (для мене). Звичайно, вони зробили щось для зменшення складності, як-от створили спеціальні простори імен XML для зменшення кількості конфігурації XML, але для мене це не стосується моєї особистої основної проблеми з Spring Security: його назви та поняття часто плутають загалом я. Важко просто «дістати».
Однак, коли ви почнете використовувати Широ, ви просто «отримаєте його». Те, що було важко зрозуміти у світі безпеки, саме те набагато простіше зрозуміти. Речі, які нестерпно важко використовувати в JDK (наприклад, Ciphers), спрощуються до рівня, який не просто переноситься, але часто користується радістю.
Наприклад, як ви хеш + солі пароль і base64 кодуєте його в Java або Spring Security? Вони не є настільки простими та інтуїтивними, як рішення Широ:
ByteSource salt = new SecureRandomNumberGenerator().nextBytes();
new Sha512Hash(password, salt).toBase64();
Немає необхідності в commons-кодеку чи що-небудь ще. Просто банку Широ.
Що стосується середовищ Spring, більшість розробників Shiro використовують Spring як основне середовище застосування. Це означає, що весняна інтеграція Широ є чудовою, і вона працює надзвичайно добре. Ви можете бути впевнені, що якщо ви пишете програму Spring, ви матимете всебічний досвід безпеки.
Наприклад, розглянемо приклад конфігурації Spring XML в іншому дописі цього потоку. Ось як ви зробили (по суті) те ж саме в Широ:
<?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>
Хоча трохи докладніше, ніж інший весняний приклад, ІМО легше читати.
Ви також знайдете використання визначень ланцюгів фільтрів Широ, мабуть, найпростіший спосіб визначити загальні ланцюги фільтрів та веб-правила безпеки будь-коли! Набагато приємніше, ніж визначати їх у web.xml.
Нарешті, Широ також пропонує надзвичайну «підключеність». Ви побачите, що ви можете налаштувати та / або замінити практично все що завгодно через POJO / зручну для ін'єкцій архітектуру Shiro. Shiro за замовчуванням майже все, щоб зменшити параметри за замовчуванням, і ви можете змінити або налаштувати лише те, що потрібно.
Зрештою, я думаю, що вибір будь-якого з цих двох стосується вашої ментальної моделі - хто з них має більше сенсу і є більш інтуїтивним для вас? Для одних це буде Широ, для інших - Весняна безпека. Широ чудово працює у весняних умовах, тому я б сказав, вибирайте, виходячи з того, яке з двох вам більше подобається, і має для вас найбільш сенс.
Докладніше про весняну інтеграцію Широ: http://shiro.apache.org/spring.html
У мене немає досвіду використання Shiro, і я "частково" згоден з тим, що ви сказали про Spring Security. До Spring Security 3.x, Spring Security (або Acegi) було дуже болісно налаштовувати. Проста конфігурація на основі ролей займе щонайменше 140 рядків криптичної конфігурації XML ... Я це знаю, тому що насправді я сам лічив рядки. Це було те, де ви налаштували один раз, і ви молитеся, що воно буде працювати назавжди, не торкаючись конфігурації знову, тому що ви можете запевнити, що ви забули, що означає вся конфігурація. :)
З Spring Security 3.x він надзвичайно покращився. Він представляє securityпростір імен, який різко скорочує конфігурацію з 140 рядків до ~ 30 рядків. Ось приклад Spring Security 3.x одного з моїх проектів: -
<?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>
Краса Spring Security 3.x в тому, що вона надзвичайно налаштована, що сприяє одному з головних мінусів: занадто складному для розуміння. Документацію читати непросто, оскільки я лише частково знайомий з деякими термінами, які використовуються Spring Security. Однак варіанти є, якщо вам потрібно створити власну налаштовану конфігурацію або контролювати, наскільки детальним ви хочете бути захищеним. Або ж ви можете дотримуватися вищевказаних рядків <30, щоб виконати перевірку безпеки на основі ролей.
Що мені дуже подобається у Spring Security - це лише після його налаштування, безпека інтегрується в проект безперешкодно. Це як би фактичний код проекту не знає існування захисту ... і це добре, тому що це дозволяє мені легко від'єднати або оновити компонент безпеки в майбутньому (наприклад: змінити базу даних auth на LDAP / CAS авт).
Я використовував Spring Security (версія 3.1) протягом декількох місяців і був дуже задоволений цим. Це дійсно потужно і має дуже приємну особливість, особливо після впровадження всього вручну, як я робив раніше! Це було, як я десь читав, щось таке, що ви налаштували один раз на початку розробки програми, а потім моліться, щоб він продовжував працювати до кінця, тому що якщо вам доведеться виправити це, ви будете напевно, ви забули більшість речей, які вам довелося налаштувати.
Але потім з'явився новий проект із складнішими вимогами до безпеки. Коротше кажучи, нам довелося реалізувати якусь власну SSO між парою пов’язаних веб-сайтів.
Я точно знав, чого хочу досягти в плані логіки HTTP, файлів cookie, ідентифікаторів сеансу та іншого, і що повинно відбуватися в тому порядку, але я витратив більшу частину дня на боротьбу з Spring Security API, і досі не міг зрозуміти точно визначте, який клас чи інтерфейс я маю реалізувати або переосмислити, і як їх підключити до контексту. Весь API відчував себе справді складною і часом езотеричною. І хоча doc є досить хорошим для загальних випадків використання та навіть деякої настройки, він не заглибився, щоб покрити мої потреби.
Прочитавши відповіді тут і в деяких інших місцях в Інтернеті, у мене склалося враження, що Широ буде легше зрозуміти і налаштувати під мої потреби. Тож я спробував це.
І я радий, що зробив це, адже після робочого дня над ним мені вдалося дізнатися достатньо про API не тільки для того, щоб без проблем створити базову систему аутентифікації та авторизації у моєму весняному веб-сайті Spring, а й реалізувати власну поведінку SSO, якою я був шукаю. Мені довелося розширити лише 2 або 3 класи, і все це займало лише близько 25 рядків конфігурації XML у моєму весняному контексті.
Отже, як висновок, щодо простоти використання та вивчення кривих аспектів, Широ дійсно дуже подобається, і я думаю, що я, мабуть, пітиму з цим у майбутньому, якщо я не зіткнуся з деякими особливостями, які бракують чи іншою проблемою (якої у мене немає так далеко).
TL; DR: Обидва є потужними, але Широ навчитися набагато простіше.