Şu anda Java tabanlı güvenlik çerçevelerini değerlendiriyorum, Spring 3.0 kullanıcısıyım, bu yüzden SpringSecurity doğru seçim olacak gibi görünüyordu, ancak Spring güvenliği aşırı karmaşıklıktan muzdarip görünüyor, kesinlikle güvenliği uygulamayı kolaylaştırıyor gibi görünmüyor, Shiro çok daha tutarlı ve anlaşılması daha kolay görünüyor. Bu iki çerçeve arasındaki artıları ve eksileri içeren bir liste arıyorum.
Yanıtlar:
Ben de Spring Security'nin çok karmaşık göründüğüne katılıyorum (bana). Tabii, XML yapılandırma miktarını azaltmak için özel XML ad alanlarını oluşturmak gibi karmaşıklığını azaltmak için şeyler yapmış, ama benim için bu adresi yok benim Bahar Security ile kişisel temel sorununu: kendi isim ve kavramlar sıklıkla generalliğe içinde kafa karıştırıcıdır ben mi. Sadece 'elde etmek' zor.
Shiro'yu kullanmaya başladığınız anda, sadece 'anlıyorsunuz'. Güvenlik dünyasında anlaşılması zor olan şey, anlaşılması çok daha kolay. JDK'da kullanımı dayanılmaz derecede zor olan şeyler (örneğin, Şifreler), sadece katlanılabilir değil, aynı zamanda kullanımı zevkli bir düzeye kadar basitleştirilmiştir.
Örneğin, bir parolayı nasıl hash + tuzlarsınız ve base64, Java veya Spring Security'de kodlar? İkisi de Shiro'nun çözümü kadar basit ve sezgisel değildir:
ByteSource salt = new SecureRandomNumberGenerator().nextBytes();
new Sha512Hash(password, salt).toBase64();Ortak kod çözücüye veya başka bir şeye gerek yok. Sadece Shiro kavanozu.
Artık Spring ortamlarıyla ilgili olarak, Shiro geliştiricilerinin çoğu Spring'i birincil uygulama ortamı olarak kullanıyor. Bu, Shiro'nun Bahar entegrasyonunun mükemmel olduğu ve her şeyin olağanüstü derecede iyi çalıştığı anlamına gelir. Bir Spring uygulaması yazıyorsanız, çok yönlü bir güvenlik deneyimine sahip olacağınızdan emin olabilirsiniz.
Örneğin, bu ileti dizisindeki başka bir gönderideki Spring XML yapılandırma örneğini düşünün. Shiro'da aynı şeyi (esasen) şu şekilde yaparsınız:
<?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>Diğer Bahar örneğinden biraz daha ayrıntılı olmasına rağmen, IMO'yu okumak daha kolaydır.
Ayrıca Shiro'nun filtre zinciri tanımlarını kullanmanın, genel filtre zincirlerini ve web tabanlı güvenlik kurallarını tanımlamanın muhtemelen en kolay yolu olduğunu göreceksiniz! Bunları web.xml'de tanımlamaktan çok daha güzel.
Son olarak, Shiro aşırı 'takılabilirlik' de sunuyor. Shiro'nun POJO / enjeksiyon dostu mimarisi sayesinde hemen hemen her şeyi yapılandırabileceğinizi ve / veya değiştirebileceğinizi göreceksiniz. Shiro, hemen hemen her şeyi varsayılan ayarlara getirir ve yalnızca ihtiyacınız olanı geçersiz kılabilir veya yapılandırabilirsiniz.
Günün sonunda, bu ikisinden birini seçmenin daha çok zihinsel modelinizle ilgili olduğunu düşünüyorum - hangisi sizin için daha mantıklı ve daha sezgisel? Bazıları için Shiro, diğerleri için Bahar Güvenliği olacak. Shiro, Bahar ortamlarında harika çalışıyor, bu yüzden ikisinden hangisini daha çok sevdiğinizi ve sizin için en mantıklı olanı seçmenizi söyleyebilirim.
Shiro'nun Bahar entegrasyonu hakkında daha fazla bilgi için: http://shiro.apache.org/spring.html
Shiro'yu kullanma deneyimim yok ve Spring Security hakkında söylediklerinize "kısmen" katılıyorum. Spring Security 3.x'ten önce, Spring Security'yi (veya Acegi) kurmak çok zahmetliydi. Basit bir rol tabanlı konfigürasyon en az 140 satırlık şifreli XML konfigürasyonu alacaktır ... Bunu biliyorum çünkü aslında satırları kendim saydım. Bir kez kurduğunuz bir şeydi ve konfigürasyona tekrar dokunmadan sonsuza kadar çalışması için dua ediyorsunuz, çünkü tüm konfigürasyonun ne anlama geldiğini unuttuğunuzdan emin olabilirsiniz. :)
Spring Security 3.x ile muazzam bir gelişme gösterdi. securityYapılandırmayı 140 satırdan ~ 30 satıra büyük ölçüde kısaltan ad alanını tanıtır . İşte projelerimden birinden bir Spring Security 3.x örneği: -
<?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'in güzelliği, son derece yapılandırılabilir olmasıdır, bu da ana dezavantajlardan birine katkıda bulunur: anlaşılamayacak kadar karmaşık. Belgelerin okunması da kolay değil çünkü Spring Security'nin kullanılan bazı terimlerine sadece kısmen aşinayım. Bununla birlikte, özel konfigürasyonunuzu oluşturmanız veya güvenliğinizin ne kadar ayrıntılı olmasını istediğinizi kontrol etmeniz gerekiyorsa seçenekler oradadır. Ya da, rol tabanlı bir güvenlik kontrolü gerçekleştirmek için yukarıdaki <30 satıra bağlı kalabilirsiniz.
Spring Security hakkında gerçekten sevdiğim şey, bir kez kurulduktan sonra güvenliğin projeye sorunsuz bir şekilde entegre edilmesi. Sanki gerçek proje kodu, güvenliğin varlığını bilmiyormuş gibi ... ve bu iyi, çünkü gelecekte güvenlik bileşenini kolayca ayırmama veya yükseltmeme izin veriyor (örn: veritabanı kimlik doğrulamasını LDAP / CAS olarak değiştirin) kimlik doğrulaması).
Spring Security'yi (sürüm 3.1) birkaç aydır kullanıyordum ve bundan oldukça memnun kaldım. Gerçekten güçlü ve çok güzel bir özelliği var, özellikle de her şeyi daha önce yaptığım gibi elle uyguladıktan sonra! Yine de, bir yerde okuduğum gibi, uygulamanın geliştirilmesinin başlangıcına yakın bir zamanda kurduğunuz ve ardından sonuna kadar çalışmaya devam etmesi için dua ettiğiniz bir şeydi, çünkü düzeltmek zorunda kalırsanız, Muhtemelen parametrelendirmeniz gereken şeylerin çoğunu unutmuşsunuzdur.
Ama sonra daha karmaşık güvenlik gereksinimleri olan yeni bir proje ortaya çıktı. Kısacası, birkaç ilgili web uygulaması arasında bir tür özel SSO uygulamak zorunda kaldık.
HTTP mantığı, çerezler, oturum kimlikleri ve diğer şeyler açısından neye ulaşmak istediğimi ve hangi sırayla ne olması gerektiğini tam olarak biliyordum, ancak günün büyük bir kısmını Spring Security API'leriyle mücadele ederek geçirdim ve yine de anlayamadım tam olarak hangi sınıfı veya arabirimi uygulayacağımı veya geçersiz kılacağımı ve bunları bağlama nasıl dahil edeceğimi öğrenin. Tüm API, zaman zaman gerçekten karmaşık ve biraz ezoterik hissediyordu. Ve belge genel kullanım durumları ve hatta bazı özelleştirmeler için oldukça iyi olsa da, ihtiyaçlarımı karşılayacak kadar derine inmedi.
Cevapları burada ve web'deki diğer bazı yerlerde okuduktan sonra, Shiro'nun daha kolay anlaşılacağı ve ihtiyaçlarıma göre özelleştirileceği izlenimi edindim. Ben de denedim.
Ve bunu yaptığıma sevindim, çünkü üzerinde çalıştığım bir günün ardından API'ler hakkında, yalnızca Spring web uygulamamda sorunsuz bir temel kimlik doğrulama ve yetkilendirme sistemi kurmak için değil, aynı zamanda benim olduğum özel SSO davranışını da uygulamak için yeterince bilgi edindim. aramak. Yalnızca 2 veya 3 sınıfı genişletmem gerekiyordu ve her şey benim bahar bağlamımda yalnızca 25 satırlık XML yapılandırması aldı.
Sonuç olarak, kullanım kolaylığı ve öğrenme eğrisi yönleriyle ilgili olarak, Shiro gerçekten oldukça sevecen ve sanırım, eksik bazı özelliklerle veya başka bir problemle karşılaşmazsam, gelecekte muhtemelen onunla devam edeceğim. şimdiye kadar).
TL; DR: Her ikisi de güçlü, ancak Shiro'nun öğrenmesi çok daha kolay.