it-swarm-ru.tech

Широ против SpringSecurity

В настоящее время я оцениваю основы безопасности на основе Java, я являюсь пользователем Spring 3.0, поэтому казалось, что SpringSecurity был бы правильным выбором, но безопасность Spring, похоже, страдает от чрезмерной сложности, но, конечно, она не выглядит так, как она есть. Широ, по-видимому, упрощает внедрение системы безопасности и делает ее более понятной и понятной. Я ищу списки плюсов и минусов между этими двумя рамками.

130
ams

Я тоже согласен, что Spring Security кажется слишком сложным (для меня). Конечно, они сделали что-то, чтобы уменьшить сложность, например, создали собственные пространства имен XML, чтобы уменьшить количество конфигурации XML, но для меня это не относится к моему личная принципиальная проблема со Spring Security: ее названия и концепции часто сбивают меня с толку. Трудно просто "получить это".

В тот момент, когда вы начинаете использовать Shiro, вы просто "получаете это". То, что было трудно понять в мире безопасности, гораздо легче понять. Вещи, которые невыносимо трудно использовать в JDK (например, шифры), упрощены до уровня, который не просто терпим, но часто и радует в использовании.

Например, как вы хешируете + солите пароль и Base64 кодируете его в Java или Spring Security? Ни один из них не так прост и интуитивно понятен, как решение Широ:

ByteSource salt = new SecureRandomNumberGenerator().nextBytes();
new Sha512Hash(password, salt).toBase64();

Нет необходимости в обычном кодеке или чем-то еще. Просто баночка Широ.

Что касается сред Spring, большинство разработчиков Shiro используют Spring в качестве своей основной среды приложений. Это означает, что интеграция Spring с Shiro превосходна, и все это работает исключительно хорошо. Вы можете быть уверены, что если вы пишете приложение 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, легче читать IMO.

Вы также обнаружите, что использование определений цепочек фильтров Shiro, вероятно, является самым простым способом определения общих цепочек фильтров и правил безопасности на основе веб-технологий! Гораздо приятнее, чем их определение в web.xml.

Наконец, Shiro также предлагает экстремальные возможности подключения. Вы увидите, что вы можете настраивать и/или заменять практически все что угодно благодаря архитектуре Shiro с POJO/дружественной инъекцией. Широ по умолчанию почти все вменяет по умолчанию, и вы можете переопределить или настроить только то, что вам нужно.

В конце концов, я думаю, что выбор одного из этих двух вариантов больше относится к вашей ментальной модели - какой из них имеет больше смысла и является более интуитивным для вас? Для некоторых это будет Широ, для других это будет Spring Security. Широ прекрасно работает в среде Spring, поэтому я бы сказал, выбирайте, основываясь на том, какой из двух вам нравится больше, и имеет для вас больше смысла.

Подробнее об интеграции Широ в Spring: http://shiro.Apache.org/spring.html

116
Les Hazlewood

У меня нет опыта использования 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 авт).

31
limc

Я использовал Spring Security (версия 3.1) в течение нескольких месяцев и был очень доволен этим. Он действительно мощный и имеет очень приятную функцию, особенно после того, как все реализовано вручную, как я делал раньше! Хотя, как я где-то читал, что-то вроде того, что вы однажды настроили в начале разработки приложения, а затем помолитесь, чтобы оно продолжало работать до конца, потому что если вам нужно будет исправить это, вы будете Возможно, вы забыли большинство вещей, которые вы должны были параметрировать.

Но затем появился новый проект с более сложными требованиями безопасности. Короче говоря, нам пришлось реализовать какой-то собственный SSO между парой связанных веб-приложений.

Я точно знал, чего хочу достичь с точки зрения логики HTTP, файлов cookie, идентификаторов сеансов и прочего, и что должно происходить в каком порядке, но большую часть дня я провел, борясь с API-интерфейсами Spring Security, и все еще не мог понять точно, какой класс или интерфейс я должен реализовать или переопределить, и как включить их в контекст. Весь API иногда казался очень сложным и немного эзотерическим. И хотя документ достаточно хорош для общих случаев использования и даже для некоторых настроек, он недостаточно углублен для удовлетворения моих потребностей.

Прочитав ответы здесь и в некоторых других местах в Интернете, у меня сложилось впечатление, что Широ будет легче понять и настроить в соответствии с моими потребностями. Я попробовал.

И я рад, что я это сделал, потому что после рабочего дня я смог узнать достаточно об API, чтобы не только без проблем настроить базовую систему аутентификации и авторизации в моем веб-приложении Spring, но и реализовать собственное поведение единого входа, которым я был находясь в поиске. Мне нужно было расширить только 2 или 3 класса, и все это заняло всего около 25 строк XML-конфигурации в моем весеннем контексте.

Итак, в заключение, о простоте использования и аспектах кривой обучения, Широ действительно очень симпатичен, и я думаю, что я, вероятно, пойду с этим в будущем, если я не столкнусь с отсутствием некоторых функций или какой-либо другой проблемой (которой у меня нет до сих пор).

TL; DR: оба сильны, но Широ гораздо легче учиться.

20
Pierre Henry