2012-03-29 22 views
13

में प्रमाणीकरण को समझना मैं वर्तमान में जेबॉस एएस 7 पर चल रहे एक प्रोजेक्ट पर काम कर रहा हूं जिसके लिए विभिन्न स्रोतों से प्रमाणीकरण की आवश्यकता है। मैं प्रमाणीकरण प्रदान करने के लिए गठबंधन करने वाले विभिन्न घटकों की समझ प्राप्त करने की कोशिश कर रहा हूं।जावा अनुप्रयोग सर्वर

मेरे पास कुछ धारणाएं/अनुमान हैं कि यह सब एक साथ कैसे फिट बैठता है, लेकिन मुझे यह सुनिश्चित करना होगा कि मेरी समझ सही है। तो नीचे जो मैं समझता हूं वह जेबॉस एएस 7 के लिए प्रमाणीकरण प्रक्रिया है।


आपके पास एक सुरक्षा क्षेत्र है जो परिभाषित करता है कि उपयोगकर्ता कैसे प्रमाणीकृत हैं। इसके बाद कुछ या सभी को सुरक्षित करने के लिए यह दायरा आपके आवेदन से अवगत कराया जाता है। AS7 में यह < उपप्रणाली xmlns = "urn: jboss: डोमेन: सुरक्षा: 1.0" > तत्व में कॉन्फ़िगर किया गया है।

दायरे को डेटाबेस-एलडीएपी, स्थानीय फ़ाइल या कुछ अन्य जैसे लॉगिन-मॉड्यूल का उपयोग करके विभिन्न स्रोतों के खिलाफ उपयोगकर्ताओं को प्रमाणीकृत करने के लिए कॉन्फ़िगर किया जा सकता है। एकाधिक लॉगिन-मॉड्यूल को परिभाषित किया जा सकता है, और आप प्रमाणीकरण के लिए लॉगिन-मॉड्यूल के कुछ संयोजन को "सफल" होना चाहिए निर्दिष्ट कर सकते हैं।

वास्तविक उपयोगकर्ता नाम और पासवर्ड web.xml फ़ाइल (servlets के लिए) में परिभाषित तंत्र के माध्यम से पारित किए जाते हैं, < लॉगिन-कॉन्फ़िगर > तत्व में परिभाषित किया गया है।


यह मानते हुए कि उपरोक्त प्रक्रिया सही है (और यह नहीं हो सकता है):

  • है JAAS की तरह एक विनिर्देश के तहत इस पूरे प्रमाणीकरण प्रक्रिया गिरावट, या JAAS की एक छोटी या वैकल्पिक हिस्सा है यह कार्यविधि?
  • सभी प्रकार के < औथ-विधियों > (यानी बेसिक, डीआईजीएस्ट और फॉर्म) सभी प्रकार के लॉगिन-मॉड्यूल के साथ काम करते हैं? This page नहीं सुझाव देने के लिए प्रतीत होता है, लेकिन मैं < लॉगिन मॉड्यूल मिलान > विकल्पों < लॉगिन-config > विकल्प किसी भी स्पष्ट प्रलेखन नहीं देखा है।
  • लॉगिन-कॉन्फ़िगरेशन से लॉगिन-कॉन्फ़िगरेशन से उपयोगकर्ता नाम और पासवर्ड प्रवाह सीधे आगे लगता है, लेकिन ओपनआईडी या ओएथ जैसे सिस्टमों के साथ क्या होता है जहां मध्यस्थ कदम होते हैं (बाहरी लॉगिन पृष्ठों के लिए पुनर्निर्देशन)?
  • Seam 3 Security, Apache Shiro और Spring Security जैसी परियोजनाएं इस तस्वीर में कैसे फ़िट होंगी?
+0

यवेस के उत्तर पर अनुवर्ती करने के लिए, आप यहां अपाचे शिरो के बारे में अधिक जानकारी प्राप्त कर सकते हैं: http://shiro.apache.org यदि आपको कोई परेशानी है तो सूची में पोस्ट करने के लिए स्वतंत्र महसूस करें। – Chunsaker

उत्तर

11

जावाईई सुरक्षा विनिर्देश कंटेनर कार्यान्वयन करने वालों के लिए बहुत सी जगह छोड़ देता है, इसलिए मैं उत्तर देने के लिए जेबॉस कार्यान्वयन पर ध्यान केंद्रित करूंगा।

JBoss सुरक्षा कार्यान्वयन

JBoss JavaEE सुरक्षा लागू करने के लिए JAAS प्रमाणीकरण पर निर्भर करता है। इस तरह यह एक स्थिर एपीआई से लाभ लेता है और existing LoginModule implementations का उपयोग कर सकता है। लॉगिन मॉड्यूल का उपयोग किसी विषय को प्रमाणित करने के लिए किया जाता है लेकिन Subject पर भूमिकाएं जोड़ने के लिए भी उपयोग किया जाता है। जेएएएस प्राधिकरण, अनुमति जांच के लिए तंत्र प्रदान करता है और जेबॉस इसे आंतरिक रूप से उपयोग करता है।

JAAS LoginModule करता है न केवल पासवर्ड-आधारित प्रमाणीकरण लेकिन यह भी टोकन-आधारित प्रमाणीकरण का समर्थन करता है।

टोकन आधारित प्रमाणीकरणों

क्या JAAS को JBoss धन्यवाद में किया जा सकता का एक अच्छा उदाहरण

HTTP Negotiation support for Kerberos SPNEGO है: एक अतिरिक्त auth-method नामित SPNEGO एक बिलाव प्रमाणक के लिए धन्यवाद कार्यान्वित किया जाता है और टोकन सत्यापन JavaSE standard Kerberos LoginModule उपयोग करता है।

वैसे, LoginModule API एक आवश्यकता नहीं है, यह कुछ प्रोटोकॉल के लिए भी जटिल हो सकता है। उदाहरण के लिए, OpenID with PicketLink का समर्थन करने के लिए कार्यान्वयन केवल Servlet API का उपयोग करता है।

तीसरे पक्ष के सुरक्षा पुस्तकालयों

इन पुस्तकालयों अक्सर एक JavaEE या शुद्ध जावा संदर्भ चल रहा एक आवेदन करने के लिए सुरक्षा परतों प्रदान करते हैं, भले ही यह प्रमाणीकरण या भूमिका आधारित प्राधिकरण के लिए JavaEE विनिर्देशों से लाभ नहीं ले करता है।

स्प्रिंग सिक्योरिटी अनुप्रयोग डेवलपर्स के प्रमाणीकरण और प्रमाणीकरण को लागू करने के लिए जावाईई सुरक्षा की तुलना में अन्य अवशोषण प्रदान करता है, मुख्य रूप से ServletFilter के लिए धन्यवाद जब एक वेब एप्लिकेशन का संबंध है। अपने आवेदन को सुरक्षित करने के लिए विकल्पों का एक बड़ा पैनल उपलब्ध है: जेएएएस उपयोग, जावाईई कंटेनर सुरक्षा उपयोग या वसंत सुरक्षा विशिष्ट कार्यान्वयन (ओपनआईडी और ओएथ का मामला) जैसे कई विकल्पों को मिश्रण करना संभव है। JavaEE पर कोई निर्भरता नहीं है, इसलिए जावाएसई पर चलते समय इसे किसी भी स्थिति में उपयोग किया जा सकता है। अधिकांश वास्तुकार भविष्य में विशिष्ट कार्यान्वयन को बदलने की स्वतंत्रता रखने के लिए वसंत सुरक्षा पर आवेदन सुरक्षा का निर्माण करना चुनते हैं।

अपाचे शिरो वास्तव में वसंत सुरक्षा के समान है लेकिन यह स्थापित करने के लिए छोटा और संभवतः आसान है।

सीम सुरक्षा जावाईई सुरक्षा या जेबॉस पर निर्भर नहीं है बल्कि केवल सर्वलेट और जेएसएफ एपीआई पर निर्भर है। यह जेएसएफ/सीम-आधारित वेब एप्लिकेशन के लिए सबसे आसान विकल्प है। दृश्य के पीछे, यह PicketLink कार्यान्वयन का उपयोग करता है। आवेदन जटिलता, विक्रेता स्वतंत्रता और पोर्टेबिलिटी, बग फिक्स या सुधार के लिए कार्यान्वयन पर नियंत्रण:

एक निष्कर्ष, प्रश्न अलावा या JavaEE सुरक्षा के लिए प्रतिस्थापन में तीसरे पक्ष के पुस्तकालयों का उपयोग करने के लिए के रूप में वास्तु विकल्पों पर निर्भर करता है। आपके विशिष्ट संदर्भ में, एकाधिक प्रमाणीकरण स्रोतों के साथ स्प्रिंग सिक्योरिटी जैसे लचीले समाधान की आवश्यकता होती है जो authentication provider chaining (या शिरो) का समर्थन करता है।

संबंधित मुद्दे