जेएसएफ: प्रमाणीकरण और प्रमाणीकरण,

Question

आगे बढ़ने का सबसे अच्छा तरीका मैंने पूरे दिन गुगलिंग और प्रमाणीकरण और प्रमाणीकरण को लागू करने के लिए सर्वोत्तम समाधान के साथ आने का प्रयास करके विभिन्न प्रश्नों को देखा है। मैं अब समाधान के हिस्से के साथ आया हूं, लेकिन उम्मीद है कि कोई अंतराल को भर सकता है। मुझे पता है वहाँ नीचे पाठ का एक बहुत है, लेकिन मेरे साथ सहन कृपया: ओ)

पृष्ठभूमि

मैं एक हिस्सा सीआरएम आवेदन पूरा जो वर्तमान में JSF 2.0, JavaEE 6, जेपीए और एक PostgreSQL का उपयोग करता है विरासत में मिली डेटाबेस। दुर्भाग्यवश, जिन लोगों ने मूल रूप से इस वेब ऐप को अपने अनंत ज्ञान में बनाना शुरू किया, उन्होंने फैसला किया कि अंत में प्रमाणीकरण/प्रमाणीकरण छोड़ना सबसे अच्छा होगा - मुझे अब इसे अंदर रखना होगा।

एप्लिकेशन अनिवार्य रूप से विभाजित है तीन परतें - विचार, प्रबंधित सेम और डीएओ। इसका मतलब यह है कि प्रबंधित सेम विशेष रूप से 'वसा' होते हैं क्योंकि उनमें सभी व्यावसायिक तर्क, सत्यापन और नेविगेशन तर्क शामिल होते हैं।

प्रमाणीकरण/प्राधिकरण आवश्यकताओं

1. प्रपत्र आधारित प्रमाणीकरण, PostgreSQL डेटाबेस में संग्रहीत साख के खिलाफ मान्य।
2. एकमात्र पृष्ठ जो सार्वजनिक रूप से सुलभ होगा (अज्ञात उपयोगकर्ताओं द्वारा) लॉगिन पृष्ठ होगा।
3. मुझे उपयोगकर्ताओं की भूमिका के आधार पर एप्लिकेशन के कुछ क्षेत्रों तक पहुंच को रोकने की आवश्यकता है। उदाहरण के लिए, केवल 'व्यवस्थापक' भूमिका वाले उपयोगकर्ता उपयोगकर्ता पृष्ठ बनाने/संपादित करने में सक्षम होना चाहिए।
4. मुझे किसी पृष्ठ के कुछ क्षेत्र तक पहुंच प्रतिबंधित करने में भी सक्षम होना चाहिए। उदाहरण के लिए, 'सेल्स रिप' भूमिका वाले उपयोगकर्ता को ग्राहक विवरण देखने में सक्षम होना चाहिए, लेकिन अगर उपयोगकर्ता की 'ग्राहक सेवा' भूमिका है तो सेव/एडिट बटन केवल तभी प्रदर्शित किया जाना चाहिए।

मैं कहाँ

पर हूँ पहली बात मैं कर रहा पर योजना इस User Authentication and Authorization using JAAS and Servlet 3.0 Login उदाहरण का अनुसरण करने के लिए है। यह मेरा मानना ​​है कि मेरी पहली 3 आवश्यकताओं को पूरा करेगा।

पृष्ठों पर सहेजें बटन आदि को दिखाने/छुपाने के लिए, मैं this SO answer में वर्णित तकनीक का उपयोग कर सकता हूं। यह आंशिक रूप से आवश्यकता 4 को हल करेगा, हालांकि मुझे लगता है कि मुझे अभी भी एक्शन विधियों और प्रबंधित बीन्स को सुरक्षित करने की आवश्यकता है। उदाहरण के लिए, मैं ग्राहक बीन पर सहेजने() विधि में एक एनोटेशन या कुछ जोड़ने में सक्षम होना चाहता हूं ताकि यह सुनिश्चित किया जा सके कि 'ग्राहक सेवा' भूमिका वाले उपयोगकर्ता ही इसे कॉल कर सकें - यह वह जगह है जहां मैं मुद्दों में भागना शुरू करता हूं ।

मुझे लगता है कि एक विकल्प कुछ ऐसा करने के लिए होगा जो मैं दृश्य में करने का प्रस्ताव कर रहा हूं और चेहरे का उपयोग कर सकता हूं यह जांचने के लिए कि वर्तमान उपयोगकर्ता "भूमिका में है"। मैं इस पर उत्सुक नहीं हूं क्योंकि यह सिर्फ मेरे कोड को अव्यवस्थित करेगा और इसके बजाय एनोटेशन का उपयोग करेगा। अगर मैं इस मार्ग से नीचे गया तो, मैं http 403 स्थिति कैसे वापस करूँगा?

javax.annotation.security। * एनोटेशन आवेदन के क्षेत्रों में घोषणात्मक रूप से निश्चित पहुंच के लिए एक अच्छा फिट प्रतीत होता है, हालांकि जहां तक ​​मैं समझता हूं, उन्हें केवल ईजेबी में जोड़ा जा सकता है। इसका मतलब यह होगा कि मुझे अपने सभी व्यावसायिक तर्कों को प्रबंधित बीन्स से बाहर ले जाना होगा जहां यह वर्तमान में नए ईजेबी के पास रहता है। मुझे लगता है कि व्यापारिक तर्क को अपने स्वयं के वर्गों (प्रतिनिधियों, सेवाओं या जो भी आप उन्हें कॉल करना चुनते हैं) में अलग करने का अतिरिक्त लाभ होगा।यह काफी बड़ा रिफैक्टर होगा हालांकि यूनिट टेस्ट या एकीकरण परीक्षण की कमी से सहायता प्राप्त नहीं की जा रही है। मुझे यकीन नहीं है कि एक्सेस नियंत्रण की ज़िम्मेदारी इस नए सेवा स्तर पर होनी चाहिए - मुझे लगता है कि यह प्रबंधित सेम पर होना चाहिए।

अन्य विकल्प

अपना शोध के दौरान मैं इस तरह के वसंत और सीवन के रूप में चौखटे उल्लेख बहुत से लोग मिल गया है। मेरे पास सीम के साथ कुछ सीमित अनुभव है, मुझे लगता है कि यह इस परियोजना के लिए एक अच्छा फिट होगा और मुझे याद है कि मुझे लगता है कि यह मेरे पास प्राधिकरण के मुद्दों को हल करता है, लेकिन मुझे लगता है कि इसे आज पेश करने में बहुत देर हो चुकी है ।

मैंने शिरो को विभिन्न स्थानों पर भी देखा है। 10 minute tutorial पर ध्यान देने के बाद यह एक अच्छा फिट लग रहा था, खासकर Deluan Quintao's taglib के साथ संयोजन में, लेकिन मैं किसी जेएसएफ वेब ऐप के साथ इसे एकीकृत करने के तरीके के बारे में कोई ट्यूटोरियल या उदाहरण नहीं ढूंढ पाया।

दूसरा विकल्प मैं आश्चर्यजनक रूप से नियमित रूप से आ गया हूं एक कस्टम समाधान लागू कर रहा है - यह मेरे लिए पागल लगता है!

सारांश

सारांश में तो, मैं वास्तव में क्या मैं प्रमाणीकरण और प्राधिकरण और कैसे लागू करने के मामले में सही रास्ते नीचे की ओर बढ़ रहा है पर कुछ मार्गदर्शन की तरह मैं हासिल करने व्यक्ति की कि लापता टुकड़ा ले लेंगे, जिसे विधियों और/या प्रबंधित सेम (या कम से कम कोड वे प्रतिनिधि) और/या कैसे मैं मैन्युअल रूप से एक HTTP स्थिति 403

Answer 1

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

मुझे अपने आवेदन को डेटाबेस से ठीक से बात करने के लिए create a mysql module था और उसके बाद डीएओ बनाने के लिए लागू किए गए कारखाने को हटा दें और उन्हें ईजेबी के बदले में परिवर्तित करें। लेनदेन प्रकार को जेटीए में सेट करने और जेटीए डेटा स्रोत का संदर्भ देने के लिए मुझे जोड़ा गया डेटासोर्स और persistence.xml संदर्भित करने के लिए hibernate.cfg.xml को भी अद्यतन करना पड़ा। एकमात्र अन्य जटिलता यह थी कि ओपन सत्र इन व्यू पैटर्न का इस्तेमाल किया जा रहा था जिसका मतलब था कि जब मैंने विचारों में प्रवेश किया था तब मैं आलसी आलसी प्रारंभिक त्रुटियों के साथ समाप्त हुआ था। मैंने इस जवाब के निचले हिस्से में दिखाए गए फ़िल्टर को फिर से कार्यान्वित किया, इसके आसपास जाने के लिए। मैं इस क्षेत्र को फिर से प्रतिक्रिया देने और फ़िल्टर की आवश्यकता को हटाने से पहले चीजों को फिर से काम करने के लिए एक अस्थायी उपाय के रूप में देखता हूं।

जेबॉस में जाने से बस एक दिन में लिया गया और मुझे यकीन है कि अगर मैं जावा ईई और मेवेन के साथ अधिक अनुभवी था तो यह बहुत तेज़ हो सकता था। अब जब मैं उस बिंदु पर हूं, तो मैं इस परियोजना में सीम 3 सुरक्षा को छोड़ने और उस समाधान का एक साथ हैक करने की कोशिश करने के बजाय, जिस दिशा में मैं जा रहा था, उसे हल करने की कोशिश करने के लिए एक अच्छी स्थिति में हूं। सीम 3 के बारे में अच्छी बात यह है कि आप कुछ हद तक चुन सकते हैं और चुन सकते हैं कि आप कौन से मॉड्यूल का उपयोग पूरे ढांचे को जोड़ने के बजाय करते हैं (जैसे सीम 2)। मुझे लगता है कि कई अन्य मॉड्यूल भी सहायक होने जा रहे हैं और अन्य चीजों के साथ मुझे देखने के पैटर्न में खुले सत्र से छुटकारा पाने में मदद करेंगे।

सीम का उपयोग करने के साथ मुझे चिंता करने वाली एक बात यह थी कि मुझे DeltaSpike के बारे में बताया गया था। ऐसा लगता है कि यह शायद सीम को प्रतिस्थापित करेगा और सीम के किसी भी संस्करण के लिए कोई योजना नहीं है। मैंने फैसला किया है कि चूंकि सीम अभी भी समर्थित है और यदि डेल्टास्पिक को सीम 3 के रूप में सफल होने में काफी समय लगता है, तो सीम 3 का उपयोग करना बहुत सुरक्षित है।

मुझे आशा है कि एक उचित ब्लॉग पोस्ट लिखने के लिए मुझे उम्मीद है उचित प्रवास में यह प्रवासन।

public class OSVRequestFilter implements Filter { 

    private static final String UserTransaction = "java:comp/UserTransaction"; 

    private static Logger logger = LoggerFactory.getLogger(EntityManagerRequestFilter.class); 

    public void init(FilterConfig config) throws ServletException { 
    } 

    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { 
     if (request instanceof HttpServletRequest) { 
      doFilter(request, response, chain, getUserTransaction()); 
     } 
    } 

    private UserTransaction getUserTransaction() throws ServletException { 
     try { 
      Context ctx = new InitialContext(); 
      return (UserTransaction)PortableRemoteObject.narrow(ctx.lookup(UserTransaction), UserTransaction.class); 
     } 
     catch (NamingException ex) { 
      logger.error("Failed to get " + UserTransaction, ex); 
      throw new ServletException(ex); 
     } 
    } 

    private void doFilter(ServletRequest request, ServletResponse response, FilterChain chain, UserTransaction utx) throws IOException, ServletException { 
     try { 
      utx.begin(); 

      chain.doFilter(request, response); 

      if (utx.getStatus() == Status.STATUS_ACTIVE) 
       utx.commit(); 
      else 
       utx.rollback(); 
     } 
     catch (ServletException ex) { 
      onError(utx); 
      throw ex; 
     } 
     catch (IOException ex) { 
      onError(utx); 
      throw ex; 
     } 
     catch (RuntimeException ex) { 
      onError(utx); 
      throw ex; 
     } 
     catch (Throwable ex){ 
      onError(utx); 
      throw new ServletException(ex); 
     } 
    } 

    private void onError(UserTransaction utx) throws IOException, ServletException { 
     try { 
      if ((utx != null) && (utx.getStatus() == Status.STATUS_ACTIVE)) 
       utx.rollback(); 
     } 
     catch (Throwable e1) { 
      logger.error("Cannot rollback transaction", e1); 
     } 
    } 

    public void destroy() { 
    } 
} 

Answer 2

आप स्प्रिंग सुरक्षा के साथ कुछ भी करने की कोशिश की लौट सकते हैं - नवीनतम जा रहा है संस्करण 3

http://janistoolbox.typepad.com/blog/2010/03/j2ee-security-java-serverfaces-jsf-spring-security.html

http://ocpsoft.org/java/jsf-java/spring-security-what-happens-after-you-log-in/

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

आप तरीकों कि आपके द्वारा लिखी गई http://blog.solidcraft.eu/2011/03/spring-security-by-example-securing.html

@PreAuthorize ("hasRole ('ROLE_XXX')") जिस तरह से

एक पृष्ठ सुरक्षित के कुछ तत्वों को बनाने के लिए सुरक्षित कर सकते हैं है .. // सामग्री

अधिक पढ़ने और उदाहरण http://static.springsource.org/spring-security/site/petclinic-tutorial.html