मैंने वर्तमान में जावा आधारित सुरक्षा ढांचे का मूल्यांकन किया है, मैं एक स्प्रिंग 3.0 उपयोगकर्ता हूं, ताकि ऐसा लगे कि स्प्रिंगसेक्विटी सही विकल्प होगा, लेकिन स्प्रिंग सुरक्षा अत्यधिक जटिलता से ग्रस्त लगती है, निश्चित रूप से ऐसा नहीं लगता कि यह सुरक्षा को लागू करना आसान बना रहा है, Shiro अधिक सुसंगत और समझने में आसान लगता है। मैं इन दो रूपरेखाओं के बीच पेशेवरों और विपक्षों की सूची देख रहा हूं।
जवाबों:
मैं यह भी मानता हूं कि स्प्रिंग सिक्योरिटी बहुत जटिल (मुझे) लगती है। बेशक, वे बातें, जटिलता को कम करने के लिए कस्टम एक्सएमएल नामस्थान बनाने एक्सएमएल विन्यास की मात्रा को कम करने के लिए की तरह किया है, लेकिन मेरे लिए, इन का पता नहीं मेरी स्प्रिंग सुरक्षा के साथ व्यक्तिगत मूलभूत मुद्दे को हैं: इसके नाम और अवधारणाएं अक्सर सामान्य रूप से भ्रमित होती हैं मुझे। बस 'इसे हासिल करना' मुश्किल है।
दूसरा आप शिरो का उपयोग करना शुरू करते हैं, हालांकि, आप बस इसे प्राप्त करते हैं। सुरक्षा की दुनिया में जो समझना मुश्किल था, उसे समझना इतना आसान है। ऐसी चीजें जो जेडीके (जैसे सिफर्स) में उपयोग करने के लिए असहनीय रूप से कठिन होती हैं, उन्हें एक स्तर पर सरल किया जाता है जो कि केवल बीबरबल नहीं है, लेकिन अक्सर उपयोग करने के लिए एक खुशी है।
उदाहरण के लिए, आपने हैश + सॉल्ट को एक पासवर्ड और बेस 64 को जावा या स्प्रिंग सिक्योरिटी में कैसे एनकोड किया है? न ही शेरो के समाधान के रूप में सरल और सहज हैं:
ByteSource salt = new SecureRandomNumberGenerator().nextBytes();
new Sha512Hash(password, salt).toBase64();कॉमन्स-कोडेक या कुछ और के लिए कोई ज़रूरत नहीं है। बस शेरो जार।
अब स्प्रिंग वातावरण के संबंध में, शिरो डेवलपर्स के अधिकांश वसंत को अपने प्राथमिक अनुप्रयोग वातावरण के रूप में उपयोग करते हैं। इसका मतलब है कि शिरो का स्प्रिंग एकीकरण शानदार है और यह सभी असाधारण रूप से अच्छी तरह से काम करता है। आप निश्चिंत हो सकते हैं कि यदि आप एक स्प्रिंग ऐप लिख रहे हैं, तो आपके पास एक अच्छी तरह गोल सुरक्षा अनुभव होगा।
उदाहरण के लिए, इस धागे में एक अन्य पोस्ट में स्प्रिंग एक्सएमएल कॉन्फ़िगरेशन उदाहरण पर विचार करें। यहाँ है कि आप शिरो में एक ही चीज़ (अनिवार्य रूप से) कैसे करेंगे:
<?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>हालांकि अन्य स्प्रिंग उदाहरण की तुलना में थोड़ा अधिक क्रियात्मक है, आईएमओ को पढ़ना आसान है।
आपको यह भी पता चलेगा कि शेरो की फ़िल्टर श्रृंखला परिभाषाओं का उपयोग करना शायद सामान्य फ़िल्टर श्रृंखलाओं और वेब-आधारित सुरक्षा नियमों को परिभाषित करने का सबसे आसान तरीका है! Web.xml में उन्हें परिभाषित करने की तुलना में बहुत अच्छा है।
अंत में, शिरो चरम 'प्लगेबिलिटी' प्रदान करता है। आप देखेंगे कि आप शिरो के POJO / इंजेक्शन के अनुकूल वास्तुकला के कारण कुछ भी कॉन्फ़िगर और / या बदल सकते हैं। शिरो ने लगभग सभी चीज़ों को डिफ़ॉल्ट रूप से डिफॉल्ट कर दिया और आप केवल उसी चीज़ को ओवरराइड या कॉन्फ़िगर कर सकते हैं जिसकी आपको आवश्यकता है।
दिन के अंत में, मुझे लगता है कि इन दोनों में से किसी एक को चुनना आपके मानसिक मॉडल के बारे में अधिक है - दोनों में से कौन अधिक समझदार है और आपके लिए अधिक सहज है? कुछ के लिए यह शिरो होगा, दूसरों के लिए यह स्प्रिंग सिक्योरिटी होगी। शिरो वसंत के वातावरण में बहुत अच्छा काम करता है, इसलिए मैं कहूंगा कि आप दोनों में से किसके आधार पर आप अधिक आनंद लेते हैं और आपको सबसे अधिक समझ में आता है।
शिरो के स्प्रिंग एकीकरण पर अधिक जानकारी के लिए: http://shiro.apache.org/spring.html
मेरे पास शेरो का उपयोग करने का अनुभव नहीं है, और मैं "आंशिक रूप से" सहमत हूं कि आपने स्प्रिंग सिक्योरिटी के बारे में क्या कहा। स्प्रिंग सिक्योरिटी 3.x से पहले, स्प्रिंग सिक्योरिटी (या Acegi) को स्थापित करने के लिए बहुत दर्दनाक था। एक साधारण रोल-आधारित कॉन्फ़िगरेशन क्रिप्टिक XML कॉन्फ़िगरेशन की कम से कम 140 लाइनें लेगा ... मुझे यह पता है क्योंकि मैंने वास्तव में खुद को लाइनों की गिनती की थी। यह कुछ ऐसा था जहां आप एक बार सेट करते हैं, और आप प्रार्थना करते हैं कि यह आपके बिना कॉन्फ़िगरेशन को फिर से छूने के बिना हमेशा के लिए काम करेगा, क्योंकि आप आश्वस्त कर सकते हैं कि आप भूल गए हैं कि सभी कॉन्फ़िगरेशन का क्या मतलब है। :)
स्प्रिंग सिक्योरिटी 3.x के साथ, इसमें काफी सुधार हुआ है। यह परिचय देता हैsecurity नेमस्पेस का है जो 140 लाइनों से ~ 30 लाइनों तक कॉन्फ़िगरेशन को बहुत छोटा करता है। यहाँ मेरी एक परियोजना का स्प्रिंग सिक्योरिटी 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>स्प्रिंग सिक्योरिटी 3.x की सुंदरता यह बेहद विन्यास योग्य है, जो मुख्य विपक्ष में से एक में योगदान देता है: समझने के लिए बहुत जटिल। प्रलेखन को पढ़ना आसान नहीं है, क्योंकि मैं केवल उन कुछ शर्तों से परिचित हूं जिनका उपयोग स्प्रिंग सिक्योरिटी करती है। हालांकि, विकल्प वहां हैं यदि आपको अपने कस्टम कॉन्फ़िगरेशन को बनाने या नियंत्रण करने की आवश्यकता है कि आप अपनी सुरक्षा को कैसे दानेदार बनाना चाहते हैं। या फिर, आप भूमिका-आधारित सुरक्षा जांच करने के लिए उपरोक्त <30 लाइनों के साथ चिपक सकते हैं।
वसंत सुरक्षा के बारे में मुझे वास्तव में क्या पसंद है, यह एक बार सेट हो जाने के बाद सुरक्षा परियोजना में मूल रूप से एकीकृत हो जाती है। यह ऐसा है जैसे वास्तविक परियोजना कोड सुरक्षा के अस्तित्व को नहीं जानता है ... और यह अच्छा है, क्योंकि यह मुझे भविष्य में सुरक्षा घटक को आसानी से अलग करने या अपग्रेड करने की अनुमति देता है (उदा: डेटाबेस डेटाबेस को LDAP / CAS में बदलें) प्रमाणन)।
मैं कुछ महीनों से स्प्रिंग सिक्योरिटी (संस्करण 3.1) का उपयोग कर रहा था और इससे काफी खुश था। यह वास्तव में शक्तिशाली है और इसमें कुछ बहुत अच्छी सुविधा है, विशेष रूप से हाथ से सब कुछ लागू करने के बाद जैसा मैंने पहले किया था! हालाँकि ऐसा था, जैसे मैंने कहीं पढ़ा था, किसी चीज़ की तरह, जिसे आपने एक बार ऐप के डेवेलपमेंट की शुरुआत के पास सेट किया था, और फिर इसके लिए अंत तक काम करते रहने की प्रार्थना की, क्योंकि अगर आपको इसे ठीक करना है शायद आपके द्वारा पैरामीटर किए गए अधिकांश सामान भूल गए हैं।
लेकिन फिर एक नई परियोजना साथ आई, जिसमें अधिक जटिल सुरक्षा आवश्यकताएं थीं। संक्षेप में, हमें संबंधित वेबएप्स के बीच कुछ प्रकार के कस्टम एसएसओ को लागू करना था।
मुझे पता था कि HTTP लॉजिक, कुकीज, सेशन आईडी और सामान के संदर्भ में मैं क्या हासिल करना चाहता था, और किस क्रम में क्या होना चाहिए, लेकिन मैंने स्प्रिंग सिक्योरिटी एपीआई के साथ संघर्ष करते हुए एक दिन का बेहतर हिस्सा बिताया और अभी भी यह पता नहीं लगा सका। वास्तव में मैं किस वर्ग या इंटरफ़ेस को कार्यान्वित या ओवरराइड करता हूं, और उन्हें संदर्भ में कैसे प्लग किया जाए। पूरे एपीआई को वास्तव में जटिल और कई बार थोड़ा गूढ़ लगा। और जबकि डॉक सामान्य उपयोग के मामलों और यहां तक कि कुछ अनुकूलन के लिए काफी अच्छा है, यह मेरी जरूरतों को पूरा करने के लिए पर्याप्त नहीं था।
यहाँ और वेब पर कुछ अन्य स्थानों पर उत्तर पढ़ने के बाद, मुझे यह आभास हुआ कि शेरो को मेरी जरूरतों को समझना और अनुकूलित करना आसान होगा। इसलिए मैंने एक कोशिश की।
और मुझे खुशी है कि मैंने ऐसा किया, क्योंकि एक दिन काम करने के बाद मैं एपीआई के बारे में न केवल अपने स्प्रिंग वेबएप में एक बुनियादी प्रमाणीकरण और प्राधिकरण प्रणाली स्थापित करने के लिए पर्याप्त परेशानी के बिना सीखने में कामयाब रहा, बल्कि कस्टम एसएसओ व्यवहार को लागू करने के लिए भी मैं था। की तलाश में मुझे केवल 2 या 3 वर्गों का विस्तार करना था, और पूरी बात मेरे वसंत संदर्भ में XML कॉन्फ़िगरेशन की केवल 25 पंक्तियों के बारे में थी।
इसलिए निष्कर्ष के रूप में, उपयोग में आसानी और सीखने की अवस्था के पहलुओं पर, शिरो वास्तव में काफी पसंद करने योग्य है, और मुझे लगता है कि मैं शायद भविष्य में इसके साथ जाऊंगा, जब तक कि मुझे कुछ सुविधाओं की कमी या किसी अन्य समस्या का सामना न करना पड़े (जो मैंने नहीं किया है) अब तक)।
TL; DR: दोनों ही शक्तिशाली हैं, लेकिन शेरो को सीखना बहुत आसान है।