web-dev-qa-db-ja.com

Shiro vs. Spring Security

現在、Javaベースのセキュリティフレームワークを評価しています。Spring3.0のユーザーであるため、SpringSecurityが正しい選択と思われましたが、Springセキュリティは過度の複雑さに悩まされているようです。セキュリティを実装しやすくするように、Shiroはより一貫性があり、理解しやすいように思われます。

javaspringspring-securityshiro
132
ams

私もSpring Securityが複雑すぎると感じていることに同意します（私にとって）。確かに、カスタムXML名前空間を作成してXML構成の量を減らすなど、複雑さを減らすためのことをしましたが、私にとっては、これらは対処しませんmySpring Securityの個人的な基本的な問題：その名前と概念は、私にとって一般的に混乱することがよくあります。ただ「手に入れる」のは難しい。

ただし、Shiroの使用を開始する2番目は、「取得」するだけです。セキュリティの世界で理解するのが難しかったのは、それだけ理解しやすいことです。 JDKで使用するのが耐えられないほど難しいもの（例：暗号）は、単に耐えられるだけでなく、使用するのが楽しいレベルまで単純化されています。

たとえば、パスワードをハッシュ+ソルトし、base64でJavaまたはSpring Securityにエンコードする方法は？Shiroのソリューションほど単純で直感的ではありません。

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

Commons-codecなどは必要ありません。シロジャー。

現在、Spring環境に関して、Shiroの開発者のほとんどは、Springを主要なアプリケーション環境として使用しています。つまり、ShiroのSpring統合は優れており、すべてが非常にうまく機能しています。 Springアプリを作成している場合は、バランスの取れたセキュリティエクスペリエンスが得られるので安心できます。

たとえば、このスレッドの別の投稿にあるSpring XMLの構成例を考えてみましょう。 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>

他のSpringの例よりも多少冗長ですが、IMOを読む方が簡単です。

また、Shiroのフィルターチェーン定義を使用すると、一般的なフィルターチェーンとWebベースのセキュリティルールを定義する最も簡単な方法になるでしょう。 web.xmlで定義するよりもはるかに優れています。

最後に、Shiroは極端な「プラグ可能性」も提供します。 ShiroのPOJO /インジェクションに適したアーキテクチャにより、ほぼすべてを構成および/または置換できることがわかります。 Shiroはほぼすべてをデフォルトに設定し、必要なものだけをオーバーライドまたは構成できます。

結局のところ、これらの2つのどちらかを選択することは、あなたのメンタルモデルに関するものだと思います。この2つのうち、どちらがより理にかなっており、より直感的ですか？ある人にとってはShiroになり、他の人にとってはSpring Securityになります。 ShiroはSpring環境で優れた機能を発揮するため、2つのうちどちらをより楽しみ、最も理にかなっているかに基づいて選択します。

ShiroのSpring統合の詳細： http://shiro.Apache.org/spring.html

117
Les Hazlewood

私はShiroを使用した経験がなく、Spring Securityについてあなたが言ったことに「部分的に」同意します。 Spring Security 3.xより前は、Spring Security（またはAcegi）をセットアップするのは非常に苦痛でした。単純な役割ベースの構成では、少なくとも140行の不可解なXML構成が必要になります...実際に自分で行をカウントしたので、これを知っています。一度セットアップしたもので、すべての構成が何を意味するのか忘れてしまったことを保証できるので、もう一度構成に触れることなく永遠に機能することを祈ります。 :)

Spring Security 3.xでは、大幅に改善されました。構成を140行から30行に大幅に短縮するsecurity名前空間を導入します。これが私のプロジェクトの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の素晴らしい点は、非常に構成しやすいことです。これは、主な短所の1つである、理解するには複雑すぎます。 Spring Securityで使用されている用語の一部に私は部分的にしか精通していないため、ドキュメントを読むのも簡単ではありません。ただし、カスタム構成を作成したり、セキュリティを細かく制御する必要がある場合は、オプションがあります。または、上記の30行未満を使用して、役割ベースのセキュリティチェックを実行できます。

私がSpring Securityについて本当に気に入っているのは、一度設定されると、セキュリティがプロジェクトにシームレスに統合されることです。実際のプロジェクトコードはセキュリティの存在を知らないかのようです...それは良いことです、それは将来セキュリティコンポーネントを簡単に切り離したりアップグレードしたりできるからです（例：データベース認証をLDAP/CASに変更するauth）。

32
limc

私は数ヶ月間Spring Security（バージョン3.1）を使用していましたが、とても満足していました。特に前に行ったようにすべてを手作業で実装した後、それは本当に強力で、いくつかの非常に素晴らしい機能を備えています！私がどこかで読んだように、アプリの開発の開始近くに一度セットアップして、最後まで動作し続けるように祈るようなものでした。おそらく、パラメータ設定する必要があったもののほとんどを忘れているでしょう。

しかし、その後、より複雑なセキュリティ要件を伴う新しいプロジェクトが登場しました。要するに、いくつかの関連するWebアプリ間に何らかのカスタムSSOを実装する必要がありました。

HTTPロジック、Cookie、セッションIDなどの点で何を達成したいのか、どのような順序で何をすべきかを正確に知っていましたが、Spring Security APIに苦労して1日の大半を過ごしましたが、それでも理解できませんでした実装またはオーバーライドする必要があるクラスまたはインターフェイス、およびそれらをコンテキストにプラグインする方法を正確に説明します。 API全体が本当に複雑で、時には難解であると感じました。また、このドキュメントは一般的な使用例やカスタマイズにも適していますが、ニーズを十分に満たすには至りませんでした。

こことWeb上の他の場所で答えを読んだ後、私はShiroが私のニーズに合わせて理解し、カスタマイズしやすいだろうという印象を受けました。だから私はそれを試してみました。

そして、私がやったことはうれしいです.1日作業した後、問題なくSpring webappで基本的な認証および承認システムを設定するだけでなく、カスタムSSO動作を実装するためのAPIについて十分に学んだからです探している。私は2つまたは3つのクラスを拡張するだけでよく、春のコンテキストでは全体で約25行のXML構成しか必要ありませんでした。

結論として、使いやすさと学習曲線の面では、Shiroは本当にかなり好感が持てますが、不足している機能や他の問題に遭遇しない限り、おそらく今後も使用するでしょうと思いますこれまでのところ）。

TL; DR：どちらも強力ですが、Shiroの方がはるかに簡単に習得できます。

21
Pierre Henry