वसंत सुरक्षा फ़िल्टर श्रृंखला कैसे काम करती है

Question

मुझे लगता है कि स्प्रिंग सुरक्षा फ़िल्टर की श्रृंखला पर निर्मित होती है, जो अनुरोध को रोकती है, प्रमाणीकरण का पता लगाती है (अनुपस्थिति), प्रमाणीकरण प्रविष्टि बिंदु पर पुनर्निर्देशित करती है या प्राधिकरण सेवा के लिए अनुरोध पारित करती है, और अंततः अनुरोध को या तो सर्वलेट को हिट करती है या सुरक्षा अपवाद को फेंक देती है। (अनधिकृत या अनधिकृत)। DelegatingFitlerProxy इन फिल्टर को एक साथ glues करता है। अपने कार्य करने के लिए, ये फ़िल्टर एक्सेस सेवाएँ जैसे कि UserDetailsService और AuthenticationManager ।

श्रृंखला में मुख्य फिल्टर (क्रम में) हैं

• SecurityContextPersistenceFilter (JSESSIONID से प्रमाणीकरण पुनर्स्थापित करता है)
• UsernamePasswordAuthenticationFilter (प्रमाणीकरण करता है)
• ExceptionTranslationFilter (FilterSecurityInterceptor से सुरक्षा अपवादों को पकड़ें)
• FilterSecurityInterceptor (प्रमाणीकरण और प्राधिकरण अपवादों को फेंक सकता है)

मुझे भ्रम है कि इन फ़िल्टर का उपयोग कैसे किया जाता है। क्या यह है कि स्प्रिंग को फ़ॉर्म-लॉगिन प्रदान किया गया है , UsernamePasswordAuthenticationFilter केवल / लॉगिन के लिए उपयोग किया जाता है , और बाद वाले फ़िल्टर नहीं हैं? क्या प्रपत्र-लॉगिन नामस्थान तत्व इन फ़िल्टर को स्वतः कॉन्फ़िगर करता है? क्या हर अनुरोध (प्रमाणित या नहीं) गैर-लॉगिन यूआरएल के लिए FilterSecurityInterceptor तक पहुंचता है ?

क्या होगा यदि मैं JWT- टोकन के साथ अपने REST API को सुरक्षित करना चाहता हूं , जिसे लॉगिन से पुनर्प्राप्त किया गया है? मुझे दो नामस्थान कॉन्फ़िगरेशन httpटैग, अधिकार कॉन्फ़िगर करने होंगे? के लिए एक / लॉगिन के साथ UsernamePasswordAuthenticationFilterहै, और बाकी यूआरएल के लिए एक और एक, कस्टम के साथ JwtAuthenticationFilter।

क्या दो httpतत्वों का विन्यास दो बनाता है springSecurityFitlerChains? है UsernamePasswordAuthenticationFilterडिफ़ॉल्ट रूप से बंद है, जब तक मैं घोषणा form-login? मैं SecurityContextPersistenceFilterएक फ़िल्टर से कैसे प्रतिस्थापित करूं जो Authenticationमौजूदा के JWT-tokenबजाय प्राप्त होगा JSESSIONID?

Comments

फ़िल्टर का डिफ़ॉल्ट क्रम

— org.springframework.security.config.annotation.web.builders.FilterComparator

Answer 1

स्प्रिंग सुरक्षा फ़िल्टर श्रृंखला एक बहुत ही जटिल और लचीला इंजन है।

श्रृंखला में मुख्य फिल्टर (क्रम में) हैं

• SecurityContextPersistenceFilter (JSESSIONID से प्रमाणीकरण पुनर्स्थापित करता है)
• UsernamePasswordAuthenticationFilter (प्रमाणीकरण करता है)
• ExceptionTranslationFilter (FilterSecurityInterceptor से सुरक्षा अपवादों को पकड़ें)
• FilterSecurityInterceptor (प्रमाणीकरण और प्राधिकरण अपवादों को फेंक सकता है)

को देखते हुए वर्तमान स्थिर रिलीज 4.2.1 प्रलेखन , खंड 13.3 फ़िल्टर आदेश आप पूरे फिल्टर श्रृंखला के फिल्टर संगठन देख सकते हैं:

13.3 फ़िल्टर ऑर्डर करना

फ़िल्टर में जो क्रम परिभाषित किया गया है वह बहुत महत्वपूर्ण है। चाहे जो भी फ़िल्टर आप वास्तव में उपयोग कर रहे हों, क्रम इस प्रकार होना चाहिए:

1. ChannelProcessingFilter , क्योंकि इसे एक अलग प्रोटोकॉल पर पुनर्निर्देशित करना पड़ सकता है

2. SecurityContextPersistenceFilter , इसलिए एक SecurityContext को एक वेब अनुरोध के प्रारंभ में SecurityContextHolder में सेट किया जा सकता है, और SecurityContext में किसी भी परिवर्तन को HttpSession में कॉपी किया जा सकता है जब वेब अनुरोध समाप्त होता है (अगले वेब अनुरोध के साथ उपयोग के लिए तैयार)

3. ConcurrentSessionFilter , क्योंकि यह SecurityContextHolder कार्यक्षमता का उपयोग करता है और प्रमुख से चल रहे अनुरोधों को प्रतिबिंबित करने के लिए SessionRegistry को अपडेट करने की आवश्यकता है।

4. प्रमाणीकरण प्रसंस्करण तंत्र - UsernamePasswordAuthenticationFilter , CasAuthenticationFilter , BasicAuthenticationFilter आदि - ताकि SecurityContextHolder को एक वैध प्रमाणीकरण अनुरोध टोकन शामिल करने के लिए संशोधित किया जा सके

5. SecurityContextHolderAwareRequestFilter , आप अपने सर्वलेट कंटेनर में एक स्प्रिंग सुरक्षा के बारे में पता HttpServletRequestWrapper स्थापित करने के लिए यह प्रयोग कर रहे हैं

6. JaasApiIntegrationFilter , अगर एक JaasAuthenticationToken SecurityContextHolder में है इस JaasAuthenticationToken में विषय के रूप में FilterChain पर कार्रवाई करेंगे

7. याद रखेंमैंथिकेशनफिल्टर , ताकि यदि कोई पहले प्रमाणीकरण प्रसंस्करण तंत्र ने SecurityContextHolder को अपडेट नहीं किया है, और अनुरोध एक कुकी प्रस्तुत करता है जो याद रखने वाली सेवाओं को लेने में सक्षम बनाता है, एक उपयुक्त याद किया गया प्रमाणीकरण ऑब्जेक्ट वहां रखा जाएगा।

8. AnonymousAuthenticationFilter , ताकि यदि कोई पहले प्रमाणीकरण संसाधन तंत्र ने SecurityContextHolder को अपडेट नहीं किया है, तो एक अनाम प्रमाणीकरण ऑब्जेक्ट को वहां रखा जाएगा

9. ExceptionTranslationFilter , किसी भी स्प्रिंग सुरक्षा अपवाद को पकड़ने के लिए ताकि या तो एक HTTP त्रुटि प्रतिक्रिया वापस आ सके या एक उपयुक्त AuthenticationEntryPoint लॉन्च किया जा सके

10. FilterSecurityInterceptor , वेब URI की सुरक्षा के लिए और पहुँच से वंचित होने पर अपवादों को बढ़ाने के लिए

अब, मैं आपके प्रश्नों को एक-एक करके आगे बढ़ाने का प्रयास करूँगा:

मुझे भ्रम है कि इन फ़िल्टर का उपयोग कैसे किया जाता है क्या यह है कि स्प्रिंग को फ़ॉर्म-लॉगिन प्रदान किया गया है, UsernamePasswordAuthenticationFilter केवल / लॉगिन के लिए उपयोग किया जाता है, और बाद वाले फ़िल्टर नहीं हैं? क्या प्रपत्र-लॉगिन नामस्थान तत्व इन फ़िल्टर को स्वतः कॉन्फ़िगर करता है? क्या हर अनुरोध (प्रमाणित या नहीं) गैर-लॉगिन यूआरएल के लिए FilterSecurityInterceptor तक पहुंचता है?

एक बार जब आप एक <security-http>अनुभाग को कॉन्फ़िगर कर रहे हैं , तो प्रत्येक के लिए आपको कम से कम एक प्रमाणीकरण तंत्र प्रदान करना होगा। यह उन फ़िल्टरों में से एक होना चाहिए जो स्प्रिंग सिक्योरिटी डॉक्यूमेंटेशन के 13.3 फ़िल्टर ऑर्डरिंग सेक्शन में समूह 4 से मेल खाते हैं, जिसका मैंने अभी संदर्भ लिया है।

यह न्यूनतम वैध सुरक्षा है: http तत्व जिसे कॉन्फ़िगर किया जा सकता है:

<security:http authentication-manager-ref="mainAuthenticationManager" 
               entry-point-ref="serviceAccessDeniedHandler">
    <security:intercept-url pattern="/sectest/zone1/**" access="hasRole('ROLE_ADMIN')"/>
</security:http>

बस कर, ये फ़िल्टर फ़िल्टर श्रृंखला प्रॉक्सी में कॉन्फ़िगर किए गए हैं:

{
        "1": "org.springframework.security.web.context.SecurityContextPersistenceFilter",
        "2": "org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter",
        "3": "org.springframework.security.web.header.HeaderWriterFilter",
        "4": "org.springframework.security.web.csrf.CsrfFilter",
        "5": "org.springframework.security.web.savedrequest.RequestCacheAwareFilter",
        "6": "org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter",
        "7": "org.springframework.security.web.authentication.AnonymousAuthenticationFilter",
        "8": "org.springframework.security.web.session.SessionManagementFilter",
        "9": "org.springframework.security.web.access.ExceptionTranslationFilter",
        "10": "org.springframework.security.web.access.intercept.FilterSecurityInterceptor"
    }

नोट: मैं उन्हें एक साधारण RestController बनाकर प्राप्त करता हूं जो @Autowires FilterChainProxy और रिटर्न यह सामग्री है:

    @Autowired
    private FilterChainProxy filterChainProxy;

    @Override
    @RequestMapping("/filterChain")
    public @ResponseBody Map<Integer, Map<Integer, String>> getSecurityFilterChainProxy(){
        return this.getSecurityFilterChainProxy();
    }

    public Map<Integer, Map<Integer, String>> getSecurityFilterChainProxy(){
        Map<Integer, Map<Integer, String>> filterChains= new HashMap<Integer, Map<Integer, String>>();
        int i = 1;
        for(SecurityFilterChain secfc :  this.filterChainProxy.getFilterChains()){
            //filters.put(i++, secfc.getClass().getName());
            Map<Integer, String> filters = new HashMap<Integer, String>();
            int j = 1;
            for(Filter filter : secfc.getFilters()){
                filters.put(j++, filter.getClass().getName());
            }
            filterChains.put(i++, filters);
        }
        return filterChains;
    }

यहाँ हम देख सकते हैं कि केवल <security:http>एक न्यूनतम विन्यास के साथ तत्व की घोषणा करके , सभी डिफ़ॉल्ट फ़िल्टर शामिल हैं, लेकिन उनमें से कोई भी एक प्रमाणीकरण प्रकार का नहीं है (13.3 फ़िल्टर ऑर्डरिंग अनुभाग में चौथा समूह)। तो यह वास्तव में इसका मतलब है कि सिर्फ security:httpतत्व की घोषणा करके , SecurityContextPersistenceFilter, ExceptionTranslationFilter और FilterSecurityInterceptor ऑटो-कॉन्फ़िगर हैं।

वास्तव में, एक प्रमाणीकरण प्रसंस्करण तंत्र को कॉन्फ़िगर किया जाना चाहिए, और यहां तक ​​कि सुरक्षा नामस्थान सेम प्रसंस्करण के दावे भी, जो स्टार्टअप के दौरान एक त्रुटि फेंकते हैं, लेकिन इसे प्रविष्टि-बिंदु-रेफरी विशेषता को जोड़कर बाईपास किया जा सकता है। <http:security>

यदि मैं <form-login>कॉन्फ़िगरेशन में एक मूल जोड़ देता हूं , तो इस तरह से:

<security:http authentication-manager-ref="mainAuthenticationManager">
    <security:intercept-url pattern="/sectest/zone1/**" access="hasRole('ROLE_ADMIN')"/>
    <security:form-login />
</security:http>

अब, फ़िल्टरचैन इस तरह होगा:

{
        "1": "org.springframework.security.web.context.SecurityContextPersistenceFilter",
        "2": "org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter",
        "3": "org.springframework.security.web.header.HeaderWriterFilter",
        "4": "org.springframework.security.web.csrf.CsrfFilter",
        "5": "org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter",
        "6": "org.springframework.security.web.authentication.ui.DefaultLoginPageGeneratingFilter",
        "7": "org.springframework.security.web.savedrequest.RequestCacheAwareFilter",
        "8": "org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter",
        "9": "org.springframework.security.web.authentication.AnonymousAuthenticationFilter",
        "10": "org.springframework.security.web.session.SessionManagementFilter",
        "11": "org.springframework.security.web.access.ExceptionTranslationFilter",
        "12": "org.springframework.security.web.access.intercept.FilterSecurityInterceptor"
    }

अब, यह दो फिल्टर org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter और org.springframework.security.web.authentication.ui.DefaultLoginPageGeneratingFilter बनाया है और FilterChainProxy में विन्यस्त कर रहे हैं।

तो, अब, सवाल:

क्या यह है कि स्प्रिंग को फ़ॉर्म-लॉगिन प्रदान किया गया है, UsernamePasswordAuthenticationFilter केवल / लॉगिन के लिए उपयोग किया जाता है, और बाद वाले फ़िल्टर नहीं हैं?

हां, यह उपयोगकर्ता नामपासवर्ड ऑथेंटिकेशनफिल्टर यूआरएल से मेल खाने के मामले में लॉगिन प्रोसेसिंग तंत्र को पूरा करने की कोशिश करने के लिए उपयोग किया जाता है। इस url को कॉन्फ़िगर किया जा सकता है या यहां तक ​​कि इसे बदला जा सकता है यह प्रत्येक अनुरोध से मेल खाने के लिए व्यवहार है।

आपके पास एक से अधिक प्रमाणीकरण प्रसंस्करण तंत्र एक ही FilterchainProxy (जैसे HttpBasic, CAS, आदि) में कॉन्फ़िगर हो सकते हैं।

क्या प्रपत्र-लॉगिन नामस्थान तत्व इन फ़िल्टर को स्वतः कॉन्फ़िगर करता है?

नहीं, प्रपत्र लॉगिन तत्व UsernamePasswordAUthenticationFilter को कॉन्फ़िगर करता है, और अगर आप लॉगिन-पृष्ठ url प्रदान नहीं करते हैं, तो यह org.springframework.security.web.authentication.ui.DefaultLoginPageGeneratingFilter को भी कॉन्फ़िगर करता है, जो एक साधारण ऑटोजर में समाप्त होता है। पृष्ठ।

अन्य फ़िल्टर <security:http>बिना किसी security:"none"विशेषता के एक तत्व बनाकर डिफ़ॉल्ट रूप से स्वतः कॉन्फ़िगर किए जाते हैं ।

क्या हर अनुरोध (प्रमाणित या नहीं) गैर-लॉगिन यूआरएल के लिए FilterSecurityInterceptor तक पहुंचता है?

प्रत्येक अनुरोध को उस तक पहुंचना चाहिए, क्योंकि यह वह तत्व है जो इस बात का ध्यान रखता है कि अनुरोध के पास अनुरोधित यूआरएल तक पहुंचने के अधिकार हैं या नहीं। लेकिन फ़िल्टर से पहले संसाधित किए गए कुछ फ़िल्टर केवल कॉल नहीं करने वाले फ़िल्टर श्रृंखला प्रसंस्करण को रोक सकते हैं FilterChain.doFilter(request, response);। उदाहरण के लिए, CSRF फ़िल्टर फ़िल्टर श्रृंखला प्रसंस्करण को रोक सकता है यदि अनुरोध में csrf पैरामीटर नहीं है।

क्या होगा यदि मैं JWT- टोकन के साथ अपने REST API को सुरक्षित करना चाहता हूं, जिसे लॉगिन से पुनर्प्राप्त किया गया है? मुझे दो नामस्थान कॉन्फ़िगरेशन http टैग, अधिकारों को कॉन्फ़िगर करना होगा? अन्य एक / लॉगिन के साथ UsernamePasswordAuthenticationFilter, और कस्टम के साथ REST url के लिए एक अन्य JwtAuthenticationFilter।

नहीं, आप इस तरह से करने के लिए मजबूर नहीं हैं। आप एक ही http तत्व में UsernamePasswordAuthenticationFilterऔर दोनों को घोषित कर सकते हैं JwtAuthenticationFilter, लेकिन यह इस फिल्टर के प्रत्येक के ठोस व्यवहार पर निर्भर करता है। दोनों दृष्टिकोण संभव हैं, और जो एक को चुनना है वह स्वयं की प्राथमिकताओं पर निर्भर करता है।

क्या दो http तत्वों को कॉन्फ़िगर करने से दो स्प्रिंग सिक्योरिटीफिटलरचिन बनते हैं?

हाँ यह सच है

जब तक मैं फ़ॉर्म-लॉगिन घोषित नहीं करता, तब तक UsernamePasswordAuthenticationFilter डिफ़ॉल्ट रूप से बंद हो जाता है?

हां, आप इसे मेरे द्वारा पोस्ट किए गए सभी कॉन्फ़िगरेशन में उठाए गए फ़िल्टर में देख सकते हैं

मैं SecurityContextPersistenceFilter को एक के साथ कैसे बदलूं, जो JSESSIONID के बजाय मौजूदा JWT- टोकन से प्रमाणीकरण प्राप्त करेगा?

आप SecurityContextPersistenceFilter से बच सकते हैं, बस सत्र की रणनीति को कॉन्फ़िगर कर सकते हैं <http:element>। बस इस तरह कॉन्फ़िगर करें:

<security:http create-session="stateless" >

या, इस मामले में आप इसे एक अन्य फ़िल्टर के साथ अधिलेखित कर सकते हैं, इस तरह से <security:http>तत्व के अंदर :

<security:http ...>  
   <security:custom-filter ref="myCustomFilter" position="SECURITY_CONTEXT_FILTER"/>    
</security:http>
<beans:bean id="myCustomFilter" class="com.xyz.myFilter" />

संपादित करें:

"आप एक ही फ़िल्टरचैनप्रॉक्सी में कॉन्फ़िगर किए गए एक से अधिक प्रमाणीकरण प्रसंस्करण तंत्र हो सकते हैं" के बारे में एक प्रश्न। यदि पहले (एक से अधिक कार्यान्वयन) प्रमाणीकरण फिल्टर की घोषणा करते हैं, तो क्या उत्तरार्द्ध पहले एक द्वारा किए गए प्रमाणीकरण को अधिलेखित करेगा? यह कैसे कई प्रमाणीकरण प्रदाताओं से संबंधित है?

यह अंततः प्रत्येक फ़िल्टर के कार्यान्वयन पर निर्भर करता है, लेकिन यह सच है कि बाद के प्रमाणीकरण फ़िल्टर कम से कम पूर्ववर्ती फ़िल्टर द्वारा किए गए किसी भी पूर्व प्रमाणीकरण को अधिलेखित करने में सक्षम हैं।

लेकिन ऐसा नहीं होगा। मेरे पास सुरक्षित आरईएसटी सेवाओं में कुछ उत्पादन के मामले हैं जहां मैं एक तरह के प्राधिकरण टोकन का उपयोग करता हूं जिसे एचटीपी के हेडर के रूप में या अनुरोध निकाय के अंदर दोनों प्रदान किया जा सकता है। इसलिए मैं दो फिल्टर कॉन्फ़िगर करता हूं जो उस टोकन को पुनर्प्राप्त करता है, एक मामले में एचटीटीपी हेडर से और दूसरा खुद के बाकी अनुरोध के अनुरोध निकाय से। यह सच है कि अगर एक http अनुरोध उस प्रमाणीकरण टोकन को Http हैडर के रूप में और अनुरोध निकाय के अंदर दोनों प्रदान करता है, तो दोनों फ़िल्टर प्रबंधक को यह बताते हुए प्रमाणीकरण तंत्र को निष्पादित करने का प्रयास करेंगे, लेकिन अनुरोध को जाँचने पर इसे आसानी से टाला जा सकता है। पहले से ही प्रमाणित doFilter()प्रत्येक फिल्टर की विधि की शुरुआत पर ।

एक से अधिक प्रमाणीकरण फ़िल्टर होना एक से अधिक प्रमाणीकरण प्रदाताओं से संबंधित है, लेकिन इसे बाध्य न करें। मेरे द्वारा पहले उजागर किए गए मामले में, मेरे पास दो प्रमाणीकरण फ़िल्टर हैं, लेकिन मेरे पास केवल एक प्रमाणीकरण प्रदाता है, क्योंकि दोनों फ़िल्टर एक ही प्रकार के प्रमाणीकरण ऑब्जेक्ट बनाते हैं, इसलिए दोनों स्थितियों में प्रमाणीकरण प्रबंधक इसे एक ही प्रदाता को सौंपता है।

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

इसलिए, मुझे लगता है कि यह स्पष्ट है कि न तो प्रमाणीकरण फ़िल्टर प्रमाणीकरणकर्ताओं की मात्रा निर्धारित करते हैं और न ही प्रदाता फ़िल्टर की मात्रा निर्धारित करते हैं।

इसके अलावा, प्रलेखन में कहा गया है कि SecurityContextPersistenceFilter SecurityContext की सफाई के लिए जिम्मेदार है, जो थ्रेड पूलिंग के कारण महत्वपूर्ण है। यदि मैं इसे छोड़ देता हूं या कस्टम कार्यान्वयन प्रदान करता हूं, तो मुझे मैन्युअल रूप से सफाई को लागू करना होगा, है ना? चेन को कस्टमाइज़ करते समय क्या ऐसे ही मिलते हैं?

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

SecurityContextPersistenceFilter एक में प्रतिनिधियों SecurityContextRepository कार्यान्वयन SecurityContext के लिए खोज। डिफ़ॉल्ट रूप से, एक HttpSessionSecurityContextRepository का उपयोग किया जाता है, लेकिन फ़िल्टर के किसी एक निर्माता का उपयोग करके इसे बदला जा सकता है। तो एक SecurityContextRepository लिखना बेहतर हो सकता है जो आपकी आवश्यकताओं को पूरा करता है और इसे SecurityContextPersistenceFilter में कॉन्फ़िगर करता है, इस पर विश्वास करते हुए कि यह खरोंच से सभी बनाने के बजाय व्यवहार को साबित करता है।

Comments

यह ज्ञानवर्धक व्याख्या थी। "आप एक ही फ़िल्टरचैनप्रॉक्सी में कॉन्फ़िगर किए गए एक से अधिक प्रमाणीकरण प्रसंस्करण तंत्र हो सकते हैं" के बारे में एक प्रश्न। यदि पहले (एक से अधिक कार्यान्वयन) प्रमाणीकरण फ़िल्टर घोषित करते हैं, तो क्या उत्तरार्द्ध पहले एक के द्वारा किए गए प्रमाणीकरण को अधिलेखित करेगा? यह कैसे कई प्रमाणीकरण प्रदाताओं होने से संबंधित है?

— तूओमास तोइवोनेन

इसके अलावा, प्रलेखन में कहा गया है कि SecurityContextPersistenceFilter SecurityContext की सफाई के लिए जिम्मेदार है, जो थ्रेड पूलिंग के कारण महत्वपूर्ण है। यदि मैं इसे छोड़ देता हूं या कस्टम कार्यान्वयन प्रदान करता हूं, तो मुझे मैन्युअल रूप से सफाई को लागू करना होगा, है ना? चेन को कस्टमाइज़ करते समय क्या ऐसे ही मिलते हैं?

— तुओमास तोइवोनेन

@TuomasToivonen मैंने आपके अंतिम प्रश्नों में प्रश्नों के बाद अपना उत्तर संपादित किया

— jlumietu

@jlumietu ("/ फ़िल्टरचैन) के बगल में जावा एनोटेशन में एक लापता उद्धरण है । इसके अलावा आप इस विधि को कहाँ रखते हैं? मैंने इसे एक नियंत्रक में जोड़ने की कोशिश की है और मेरे पास है:No qualifying bean of type 'org.springframework.security.web.FilterChainProxy' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {@org.springframework.beans.factory.annotation.Autowired(required=true)}

— दिमित्री कोपरिअन

@BigDong सुनिश्चित करें कि आपने दोनों Web.xml या java webapp config और अपने स्प्रिंग कॉन्फ़िगरेशन में SpringSecurityFilterChain घोषित कर दिया है। इस कोड स्निपेट को एक नियंत्रक में शामिल किया जाना चाहिए, जैसा आपने किया था। और हाँ, आप गुमशुदा बोली के बारे में

— लिख रहे हैं

Answer 2

UsernamePasswordAuthenticationFilterकेवल इसके लिए उपयोग किया जाता है /login, और बाद वाले फ़िल्टर नहीं हैं?

नहीं, UsernamePasswordAuthenticationFilterफैली हुई है AbstractAuthenticationProcessingFilter, और इसमें एक RequestMatcher, इसका मतलब है कि आप अपने स्वयं के प्रसंस्करण url को परिभाषित कर सकते हैं, यह फ़िल्टर केवल RequestMatcherअनुरोध url से मेल खाता है, डिफ़ॉल्ट प्रसंस्करण यूआरएल है /login।

बाद के फ़िल्टर अभी भी अनुरोध को संभाल सकते हैं, यदि UsernamePasswordAuthenticationFilterनिष्पादन हो chain.doFilter(request, response);।

कोर फिटलर के बारे में अधिक जानकारी

क्या प्रपत्र-लॉगिन नामस्थान तत्व इन फ़िल्टर को स्वतः कॉन्फ़िगर करता है?

UsernamePasswordAuthenticationFilterद्वारा बनाया गया है <form-login>, ये Standard Filter Aliases और Ordering हैं

क्या हर अनुरोध (प्रमाणित या नहीं) गैर-लॉगिन यूआरएल के लिए FilterSecurityInterceptor तक पहुंचता है?

यह इस बात पर निर्भर करता है कि पहले FilterSecurityInterceptorफिट करने वाले सफल हैं या नहीं, लेकिन सामान्य रूप से अंतिम फिटलर है।

क्या दो http तत्वों को कॉन्फ़िगर करने से दो स्प्रिंग सिक्योरिटीफिटलरचिन बनते हैं?

हां, हर फेल्टरचैन के पास एक है RequestMatcher, यदि RequestMatcherअनुरोध अनुरोध से मेल खाता है, तो अनुरोध को फिटलर श्रृंखला में फिट करने वालों द्वारा नियंत्रित किया जाएगा।

RequestMatcherयदि आप पैटर्न को कॉन्फ़िगर नहीं करते हैं या आप विशिष्ट url ( <http pattern="/rest/**") को कॉन्फ़िगर कर सकते हैं तो डिफ़ॉल्ट सभी अनुरोधों से मेल खाता है ।

यदि आप फिटर्स के बारे में अधिक जानना चाहते हैं, तो मुझे लगता है कि आप वसंत सुरक्षा में स्रोत कोड की जांच कर सकते हैं। doFilter(ServletRequest request, ServletResponse response, FilterChain filterChain)

Answer 3

स्प्रिंग सुरक्षा एक फ़िल्टर आधारित ढांचा है, यह प्रॉक्सी फ़िल्टर या स्प्रिंग प्रबंधित बीन्स के मामले में आपके आवेदन से पहले एक WALL (HttpFireWall) लगाता है। आपके अनुरोध को आपके एपीआई तक पहुंचने के लिए कई फिल्टरों से गुजरना पड़ता है।

वसंत सुरक्षा में निष्पादन की अनुक्रम

1. WebAsyncManagerIntegrationFilter SecurityContext और स्प्रिंग वेब के WebAsyncManager के बीच एकीकरण प्रदान करता है।
   

2. SecurityContextPersistenceFilterयह फ़िल्टर केवल एक बार अनुरोध के अनुसार निष्पादित करेगा, अनुरोध से पहले कॉन्फ़िगर किए गए SecurityContextRepository से प्राप्त जानकारी के साथ SecurityContextHolder को पॉप्युलेट करता है और अनुरोध को पूरा करने और संदर्भ धारक को खाली करने के बाद इसे भंडार में वापस संग्रहीत करता है।
   मौजूदा सत्र के लिए अनुरोध की जाँच की जाती है। यदि नया अनुरोध, SecurityContext का निर्माण किया जाएगा यदि अनुरोध में सत्र है तो मौजूदा सुरक्षा-संदर्भ को रिस्पांसरी से प्राप्त किया जाएगा ।

3. HeaderWriterFilter वर्तमान प्रतिक्रिया के लिए शीर्षकों को जोड़ने के लिए कार्यान्वयन फ़िल्टर करें।

4. LogoutFilterअनुरोध यूआरएल है /logout(डिफ़ॉल्ट विन्यास के लिए) या यदि अनुरोध यूआरएल mathces RequestMatcherमें विन्यस्त LogoutConfigurerतो

   • सुरक्षा संदर्भ को साफ करता है।
   • सत्र अमान्य है
   • कुकी के सभी कुकीज़ हटाता है जिसमें कॉन्फ़िगर नाम हैं LogoutConfigurer
   • डिफ़ॉल्ट लॉगआउट सफलता url /या लॉगआउट सफलता url कॉन्फ़िगर किया गया है या logoutSuccessHandler कॉन्फ़िगर किया गया है को पुनर्निर्देशित करता है।

5. UsernamePasswordAuthenticationFilter

   • LoginProcessingUrl के अलावा किसी भी अनुरोध के लिए यह फ़िल्टर आगे की प्रक्रिया नहीं करेगा, लेकिन फ़िल्टर श्रृंखला अभी भी जारी है।
   • यदि अनुरोध किया गया URL मिलान है (तब होना चाहिए HTTP POST) डिफ़ॉल्ट /loginया फिर .loginProcessingUrl()कॉन्फ़िगर किए गए प्रयासों से मेल खाता है ।FormLoginConfigurerUsernamePasswordAuthenticationFilter
   • डिफ़ॉल्ट लॉगिन प्रपत्र मापदंडों यूज़रनेम और पासवर्ड हैं, द्वारा अधिरोहित जा सकता है usernameParameter(String), passwordParameter(String)।
   • सेटिंग .loginPage() ओवरराइड चूक
   • प्रमाणीकरण का प्रयास करते समय
     • एक Authenticationऑब्जेक्ट ( UsernamePasswordAuthenticationTokenया Authenticationआपके कस्टम स् थन फिल्टर के मामले में कोई कार्यान्वयन ) बनाया जाता है।
     • और authenticationManager.authenticate(authToken)मंगाया जाएगा
       
     • ध्यान दें कि हम किसी भी संख्या को AuthenticationProviderप्रमाणित कर सकते हैं, विधि सभी प्रदाता को supportsआज़माती है और किसी भी प्रदाता प्रदाता के रूप में जांच करती है। और प्रमाणीकरण प्रमाणीकरण के मामले में प्रमाणीकरण वस्तु वापस आती है और फेंकता है AuthenticationException।
   • यदि प्रमाणीकरण सफलता सत्र बनाया authenticationSuccessHandlerजाएगा और इसे फिर से अपलोड किया जाएगा जो लक्षित url कॉन्फ़िगर (डिफ़ॉल्ट है /) पर पुनर्निर्देशित करता है
   • यदि प्रमाणीकरण विफल हुआ उपयोगकर्ता अन-प्रमाणित उपयोगकर्ता बन जाता है और श्रृंखला जारी रहती है।

6. SecurityContextHolderAwareRequestFilter, अगर आप इसका उपयोग स्प्रिंग सिक्योरिटी अवगत HttpServletRequestWrapper को अपने सर्वलेट कंटेनर में स्थापित करने के लिए कर रहे हैं

7. AnonymousAuthenticationFilterपता लगाता है कि SecurityContextHolder में कोई ऑथेंटिकेशन ऑब्जेक्ट नहीं है, अगर कोई ऑथेंटिकेशन ऑब्जेक्ट नहीं मिला है, तो दिए गए अथॉरिटी से Authenticationऑब्जेक्ट ( AnonymousAuthenticationToken) बनाता है ROLE_ANONYMOUS। यहां AnonymousAuthenticationTokenअन-ऑथेंटिकेटेड यूजर्स को बाद के रिक्वेस्ट को पहचानने की सुविधा है।
   

_{दोषमार्जन लॉग}

DEBUG - /app/admin/app-config at position 9 of 12 in additional filter chain; firing Filter: 'AnonymousAuthenticationFilter'
DEBUG - Populated SecurityContextHolder with anonymous token: 'org.springframework.security.authentication.AnonymousAuthenticationToken@aeef7b36: Principal: anonymousUser; Credentials: [PROTECTED]; Authenticated: true; Details: org.springframework.security.web.authentication.WebAuthenticationDetails@b364: RemoteIpAddress: 0:0:0:0:0:0:0:1; SessionId: null; Granted Authorities: ROLE_ANONYMOUS' 

8. ExceptionTranslationFilter, किसी भी स्प्रिंग सुरक्षा अपवाद को पकड़ने के लिए ताकि या तो एक HTTP त्रुटि प्रतिक्रिया लौटाया जा सके या एक उपयुक्त AuthenticationEntryPoint लॉन्च किया जा सके।

9. FilterSecurityInterceptor
   वहाँ होगा FilterSecurityInterceptorजो फ़िल्टर श्रृंखला में लगभग अंतिम आता है जिसे प्रमाणीकरण ऑब्जेक्ट मिलता है SecurityContextऔर अधिकारियों की सूची (भूमिकाओं) दी जाती है और यह निर्णय लेगा कि इस अनुरोध को अनुरोधित संसाधन तक पहुंचने दिया जाए या नहीं, निर्णय के साथ मिलान करके किया जाता है या नहीं में AntMatchersकॉन्फ़िगर करने की अनुमति है HttpSecurityConfiguration।

अपवादों पर विचार करें 401-UnAuthorized और 403-निषिद्ध। ये निर्णय फ़िल्टर श्रृंखला में आखिरी में किया जाएगा

• सार्वजनिक संसाधन तक पहुँचने की कोशिश कर रहा प्रमाणित उपयोगकर्ता - अनुमति नहीं है
  
• प्रमाणित संसाधन तक पहुँचने की कोशिश कर रहे अन-प्रमाणित उपयोगकर्ता - 401-अनअथोराइज़्ड
  
• प्रतिबंधित संसाधन (उसकी भूमिका के लिए प्रतिबंधित) तक पहुँचने की कोशिश करने वाले प्रमाणित उपयोगकर्ता - 403-निषिद्ध
  

---

नोट: उपयोगकर्ता अनुरोध न केवल उल्लेख फिल्टर ऊपर में बहती है, लेकिन वहाँ दूसरों फिल्टर भी यहाँ दिखाया गया है नहीं कर रहे हैं (। ConcurrentSessionFilter, RequestCacheAwareFilter, SessionManagementFilter...)
यह अलग है जब आप के बजाय अपने कस्टम प्रमाणन फिल्टर का उपयोग किया जाएगा UsernamePasswordAuthenticationFilter।
यह अलग होगा यदि आप JWT ऑर्टिकल फ़िल्टर को कॉन्फ़िगर करते हैं और .formLogin() i.e, UsernamePasswordAuthenticationFilterइसे छोड़ देते हैं तो यह पूरी तरह से अलग मामला बन जाएगा।

---

सिर्फ संदर्भ के लिए। वसंत-वेब और वसंत-सुरक्षा में फ़िल्टर
नोट: तस्वीर में पैकेज का नाम देखें , क्योंकि ऑरम और मेरे कस्टम कार्यान्वित फ़िल्टर से कुछ अन्य फ़िल्टर हैं।

प्रलेखन से फिल्टर के आदेश के रूप में दिया जाता है

• ChannelProcessingFilter
• ConcurrentSessionFilter
• SecurityContextPersistenceFilter
• LogoutFilter
• X509AuthenticationFilter
• AbstractPreAuthenticatedProcessingFilter
• CasAuthenticationFilter
• UsernamePasswordAuthenticationFilter
• ConcurrentSessionFilter
• OpenIDAuthenticationFilter
• DefaultLoginPageGeneratingFilter
• DefaultLogoutPageGeneratingFilter
• ConcurrentSessionFilter
• DigestAuthenticationFilter
• BearerTokenAuthenticationFilter
• BasicAuthenticationFilter
• RequestCacheAwareFilter
• SecurityContextHolderAwareRequestFilter
• JaasApiIntegrationFilter
• RememberMeAuthenticationFilter
• AnonymousAuthenticationFilter
• SessionManagementFilter
• ExceptionTranslationFilter
• FilterSecurityInterceptor
• SwitchUserFilter

आधुनिक वेब ऐप को प्रमाणित करने के लिए आप सबसे सामान्य तरीका भी बता सकते हैं ?
स्प्रिंग सिक्योरिटी के संदर्भ में प्रमाणीकरण और प्राधिकरण के बीच अंतर?