Shiro vs. SpringSecurity [ditutup]

Saat ini saya telah mengevaluasi kerangka kerja keamanan berbasis Java, saya adalah pengguna Spring 3.0 sehingga sepertinya SpringSecurity akan menjadi Pilihan yang tepat, tetapi keamanan Spring tampaknya mengalami kompleksitas yang berlebihan, tentu saja sepertinya tidak membuat keamanan lebih mudah untuk diterapkan, Shiro tampaknya jauh lebih koheren dan lebih mudah dipahami. Saya mencari daftar pro dan kontra antara kedua kerangka ini.

Saya juga setuju bahwa Spring Security terasa terlalu rumit (bagi saya). Tentu, mereka telah melakukan hal-hal untuk mengurangi kompleksitas, seperti membuat ruang nama XML khusus untuk mengurangi jumlah konfigurasi XML, tetapi bagi saya, ini tidak membahas masalah mendasar pribadi saya dengan Spring Security: nama dan konsepnya sering membingungkan secara umum untuk saya. Sulit untuk hanya 'mengerti'.

Namun begitu Anda mulai menggunakan Shiro, Anda cukup 'mengerti'. Apa yang sulit dipahami di dunia keamanan adalah jauh lebih mudah untuk dipahami. Hal-hal yang sulit untuk digunakan di JDK (mis. Ciphers) disederhanakan ke tingkat yang tidak hanya dapat ditanggung, tetapi seringkali menyenangkan untuk digunakan.

Sebagai contoh, bagaimana Anda + hash kata sandi dan base64 menyandikannya di Java atau Spring Security? Tidak ada yang sesederhana dan intuitif seperti solusi Shiro:

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

Tidak perlu commons-codec atau apa pun. Hanya toples Shiro.

Sekarang berkaitan dengan lingkungan Spring, sebagian besar pengembang Shiro menggunakan Spring sebagai lingkungan aplikasi utama mereka. Itu berarti integrasi Musim Semi Shiro luar biasa dan semuanya bekerja dengan sangat baik. Anda dapat yakin bahwa jika Anda menulis aplikasi Musim Semi, Anda akan memiliki pengalaman keamanan yang menyeluruh.

Misalnya, pertimbangkan contoh konfigurasi Spring XML di pos lain di utas ini. Inilah cara Anda melakukan (pada dasarnya) hal yang sama di 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>

Meskipun sedikit lebih bertele-tele daripada contoh Spring lainnya, lebih mudah untuk membaca IMO.

Anda juga akan menemukan menggunakan definisi rantai filter Shiro mungkin cara termudah untuk mendefinisikan rantai filter umum dan aturan keamanan berbasis web yang pernah ada! Jauh lebih bagus daripada mendefinisikannya di web.xml.

Akhirnya, Shiro juga menawarkan 'pluggability' yang ekstrem. Anda akan melihat bahwa Anda dapat mengonfigurasi dan / atau mengganti apa saja karena arsitektur POJO / injeksi ramah Shiro. Shiro default hampir semuanya menjadi waras default dan Anda dapat menimpa atau mengkonfigurasi hanya apa yang Anda butuhkan.

Pada akhirnya, saya pikir memilih salah satu dari keduanya adalah tentang model mental Anda - mana dari keduanya yang lebih masuk akal dan lebih intuitif untuk Anda? Untuk beberapa itu akan menjadi Shiro, untuk yang lain itu akan menjadi Spring Security. Shiro bekerja sangat baik di lingkungan Musim Semi, jadi saya akan mengatakan pilih berdasarkan mana dari dua yang paling Anda sukai dan yang paling masuk akal bagi Anda.

Untuk informasi lebih lanjut tentang integrasi Musim Semi Shiro: http://shiro.apache.org/spring.html

Saya tidak punya pengalaman menggunakan Shiro, dan saya "sebagian" setuju dengan apa yang Anda katakan tentang Spring Security. Sebelum Spring Security 3.x, Spring Security (atau Acegi) sangat sulit untuk diatur. Konfigurasi berbasis peran yang sederhana akan mengambil setidaknya 140 baris konfigurasi XML rahasia ... Saya tahu ini karena saya sebenarnya menghitung sendiri garis-garisnya. Itu adalah sesuatu di mana Anda mengatur satu kali, dan Anda berdoa agar itu akan bekerja selamanya tanpa Anda menyentuh konfigurasi lagi, karena Anda dapat memastikan Anda telah lupa apa arti semua konfigurasi. :)

Dengan Spring Security 3.x, ini telah sangat ditingkatkan. Ini memperkenalkan securitynamespace yang secara drastis mempersingkat konfigurasi dari 140 baris menjadi ~ 30 baris. Berikut adalah contoh Spring Security 3.x dari salah satu proyek saya: -

<?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>

Keindahan Spring Security 3.x adalah sangat dapat dikonfigurasi, yang berkontribusi pada salah satu kelemahan utama: terlalu rumit untuk dipahami. Dokumentasinya juga tidak mudah dibaca karena saya hanya sebagian akrab dengan beberapa istilah Spring Security yang digunakan. Namun, opsi ada di sana jika Anda perlu membuat konfigurasi khusus atau mengontrol seberapa rinci keamanan yang Anda inginkan. Atau yang lain, Anda dapat tetap menggunakan <30 baris di atas untuk melakukan pemeriksaan keamanan berbasis peran.

Apa yang saya benar-benar suka tentang Spring Security adalah sekali sudah diatur keamanan diintegrasikan ke dalam proyek dengan mulus. Seolah-olah kode proyek yang sebenarnya tidak mengetahui keberadaan keamanan ... dan itu bagus, karena memungkinkan saya untuk dengan mudah melepaskan atau meningkatkan komponen keamanan di masa mendatang (mis: ubah basis data auth ke LDAP / CAS auth).

Saya telah menggunakan Spring Security (versi 3.1) selama beberapa bulan dan cukup senang dengannya. Ini sangat kuat dan memiliki beberapa fitur yang sangat bagus, terutama setelah mengimplementasikan semuanya dengan tangan seperti yang saya lakukan sebelumnya! Meskipun demikian, seperti yang saya baca di suatu tempat, semacam sesuatu yang Anda siapkan sekali di dekat awal pengembangan aplikasi, dan kemudian berdoa untuknya agar tetap bekerja sampai akhir, karena jika Anda harus memperbaikinya Anda akan mungkin lupa sebagian besar hal yang Anda harus parameter.

Tetapi kemudian sebuah proyek baru muncul, dengan persyaratan keamanan yang lebih kompleks. Singkatnya, kami harus menerapkan semacam SSO khusus antara beberapa webapps terkait.

Saya tahu persis apa yang ingin saya capai dalam hal logika HTTP, cookie, sesi id dan hal-hal, dan apa yang harus terjadi dalam urutan apa, tetapi saya menghabiskan sebagian besar hari berjuang dengan API Keamanan Musim Semi, dan masih tidak dapat menemukan persis kelas atau antarmuka apa yang harus saya implementasikan atau timpa, dan bagaimana menghubungkannya dalam konteks. Seluruh API terasa sangat kompleks dan sedikit esoterik. Dan sementara dokumen ini cukup baik untuk kasus penggunaan umum dan bahkan beberapa penyesuaian, itu tidak cukup mendalam untuk memenuhi kebutuhan saya.

Setelah membaca jawaban di sini dan di beberapa tempat lain di web, saya mendapat kesan bahwa Shiro akan lebih mudah untuk memahami dan menyesuaikan dengan kebutuhan saya. Jadi saya mencobanya.

Dan saya senang saya melakukannya, karena setelah sehari bekerja di sana saya berhasil belajar cukup tentang API tidak hanya untuk mengatur otentikasi dasar dan sistem otorisasi di webapp Spring saya tanpa masalah, tetapi juga untuk menerapkan perilaku SSO khusus. mencari. Saya hanya perlu memperluas 2 atau 3 kelas, dan semuanya hanya membutuhkan sekitar 25 baris konfigurasi XML dalam konteks pegas saya.

Jadi sebagai kesimpulan, pada kemudahan penggunaan dan aspek kurva belajar, Shiro benar-benar sangat disukai, dan saya pikir saya mungkin akan pergi dengannya di masa depan, kecuali jika saya menemukan beberapa fitur yang kurang atau beberapa masalah lain (yang saya belum punya sejauh ini).

TL; DR: Keduanya kuat, tetapi Shiro lebih mudah dipelajari.