В настоящее время я оцениваю фреймворки безопасности на основе Java, я являюсь пользователем Spring 3.0, поэтому мне показалось, что SpringSecurity будет правильным выбором, но безопасность Spring, похоже, страдает от чрезмерной сложности, это, конечно, не похоже, что это облегчает реализацию безопасности, Широ кажется более последовательным и понятным. Я ищу списки плюсов и минусов этих двух фреймворков.
Ответы:
Я тоже согласен с тем, что Spring Security кажется слишком сложным (для меня). Конечно, они сделали кое-что, чтобы уменьшить сложность, например, создали пользовательские пространства имен XML, чтобы уменьшить количество XML-конфигурации, но для меня это не решает мою личную фундаментальную проблему с Spring Security: его названия и концепции часто сбивают с толку в целом. меня. Трудно просто «понять».
Но как только вы начнете использовать Широ, вы просто «поняли». То, что было трудно понять в мире безопасности, понять гораздо легче. Вещи, которые невыносимо сложно использовать в JDK (например, шифры), упрощены до уровня, который не только терпим, но и часто приносит удовольствие.
Например, как вы хешируете + солируете пароль, а base64 кодируете его в Java или Spring Security? Ни одно из них не так просто и интуитивно понятно, как решение Широ:
ByteSource salt = new SecureRandomNumberGenerator().nextBytes();
new Sha512Hash(password, salt).toBase64();Нет необходимости в общедоступном кодеке или чем-то еще. Просто банка Широ.
Что касается сред Spring, большинство разработчиков Shiro используют 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>Хотя он немного более подробный, чем другой пример Spring, его легче читать.
Вы также обнаружите, что использование определений цепочек фильтров Широ, вероятно, является самым простым способом определения общих цепочек фильтров и правил безопасности в Интернете! Намного лучше, чем определять их в web.xml.
Наконец, Shiro также предлагает исключительную «подключаемость». Вы увидите, что вы можете настроить и / или заменить что угодно благодаря архитектуре Shiro, ориентированной на POJO / инъекции. Широ устанавливает по умолчанию почти все в разумные значения, и вы можете переопределить или настроить только то, что вам нужно.
В конце концов, я думаю, что выбор любого из этих двух больше связан с вашей ментальной моделью - какая из двух имеет больше смысла и является более интуитивной для вас? Для некоторых это будет Широ, для других - Spring Security. Широ отлично работает в весенних средах, поэтому я бы сказал, выбирайте, исходя из того, какой из двух вам нравится больше и имеет для вас наибольший смысл.
Подробнее об интеграции Shiro Spring: 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, так это то, что после ее настройки безопасность интегрируется в проект без проблем. Как будто фактический код проекта не знает о существовании защиты ... и это хорошо, потому что это позволяет мне легко отсоединять или обновлять компонент безопасности в будущем (например, изменить аутентификацию базы данных на LDAP / CAS авт).
Я использовал Spring Security (версия 3.1) несколько месяцев и был им вполне доволен. Это действительно мощно и имеет очень приятную функцию, особенно после того, как я реализовал все вручную, как я это делал раньше! Хотя, как я где-то читал, что-то вроде того, что вы настраиваете один раз в начале разработки приложения, а затем молитесь, чтобы оно продолжало работать до конца, потому что, если вам придется пойти и исправить, вы вероятно, вы забыли большую часть того, что вам нужно было параметрировать.
Но затем появился новый проект с более сложными требованиями к безопасности. Короче говоря, нам пришлось реализовать своего рода настраиваемую систему единого входа между парой связанных веб-приложений.
Я точно знал, чего хочу достичь с точки зрения логики HTTP, файлов cookie, идентификаторов сеансов и прочего, и что должно происходить в каком порядке, но большую часть дня я провел, борясь с API Spring Security, и все еще не мог понять точно определить, какой класс или интерфейс я должен реализовать или переопределить, и как подключить их к контексту. Весь API казался действительно сложным и временами немного эзотерическим. И хотя документ достаточно хорош для общих случаев использования и даже для некоторой настройки, он недостаточно углублен, чтобы удовлетворить мои потребности.
Прочитав ответы здесь и в некоторых других местах в Интернете, у меня сложилось впечатление, что Широ будет легче понять и настроить в соответствии с моими потребностями. Итак, я попробовал.
И я рад, что сделал это, потому что после дня работы над этим мне удалось узнать достаточно об API не только для того, чтобы без проблем настроить базовую систему аутентификации и авторизации в моем веб-приложении Spring, но и для реализации настраиваемого поведения SSO, которым я был находясь в поиске. Мне нужно было расширить только 2 или 3 класса, и все это заняло всего около 25 строк конфигурации XML в моем контексте Spring.
Итак, в качестве заключения, касательно простоты использования и аспектов кривой обучения, Широ действительно весьма симпатичен, и я думаю, что, вероятно, буду придерживаться его в будущем, если только я не столкнусь с некоторыми отсутствующими функциями или какой-либо другой проблемой (которой у меня не было). до сих пор).
TL; DR: Оба они сильны, но Широ намного легче научиться.