132

私は現在Javaベースのセキュリティフレームワークを評価しています。私はSpring3.0ユーザーなので、SpringSecurityが正しい選択であるように見えましたが、Springセキュリティは過度の複雑さに苦しんでいるようで、セキュリティの実装を容易にしているようには見えません。シロはもっと首尾一貫していて理解しやすいようです。これら2つのフレームワーク間の長所と短所のリストを探しています。

4

3 に答える 3

118

私も、Spring Securityが（私にとって）複雑すぎると感じていることに同意します。確かに、彼らはXML構成の量を減らすためにカスタムXML名前空間を作成するなど、複雑さを減らすために何かをしましたが、私にとって、これらはSpringSecurityに関する私の個人的な基本的な問題に対処していません。自分。「それを手に入れる」だけでは難しい。

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

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

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

コモンズコーデックなどは必要ありません。ただシロジャー。

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

たとえば、このスレッドの別の投稿にあるSpringXML構成の例について考えてみます。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つのどちらかを選択することは、メンタルモデルに関するものだと思います。どちらがより理にかなっていて、より直感的ですか。シロになる人もいれば、スプリングセキュリティになる人もいます。Shiroは春の環境でうまく機能するので、2つのうちどちらがより楽しんでいて、最も理にかなっているのかに基づいて選択すると思います。

ShiroのSpring統合の詳細については、http ：//shiro.apache.org/spring.htmlを参照してください。

于 2011-02-14T21:25:21.097 に答える
32

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

Spring Security 3.xにより、大幅に改善されました。security構成を140行から最大30行に大幅に短縮する名前空間を導入します。これが私のプロジェクトの1つのSpringSecurity3.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）。

于 2011-02-14T14:16:02.727 に答える
22

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

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

HTTPロジック、Cookie、セッションIDなどの観点から何を達成したいのか、どのような順序で何を実行するのかは正確にわかっていましたが、1日の大半をSpring Security APIに苦労して過ごしましたが、それでも理解できませんでした。実装またはオーバーライドする必要のあるクラスまたはインターフェイスと、それらをコンテキストにプラグインする方法を正確に把握します。API全体が非常に複雑で、少し難解な場合もありました。また、このドキュメントは一般的なユースケースや一部のカスタマイズにも非常に適していますが、私のニーズを十分にカバーすることはできませんでした。

ここやウェブ上の他の場所で答えを読んだ後、私はシロが私のニーズに合わせて理解し、カスタマイズするのがより簡単であるという印象を受けました。だから私はそれを試してみました。

そして、私がやったことをうれしく思います。なぜなら、それに取り組んだ後、私はAPIについて十分に学び、Spring Webアプリケーションで基本認証および承認システムを問題なくセットアップするだけでなく、カスタムSSO動作を実装することもできました。探している。私は2つまたは3つのクラスを拡張するだけでよく、春のコンテキストでは全体で約25行のXML構成しか必要としませんでした。

結論として、使いやすさと学習曲線の面で、Shiroは非常に好感が持てます。機能が不足している場合やその他の問題が発生しない限り、Shiroは将来的に使用する予定です。これまでのところ）。

TL; DR：どちらも強力ですが、Shiroの方がはるかに習得しやすいです。

于 2013-09-10T16:54:45.080 に答える