आवेदन सत्र समाप्ति

Question

के साथ वसंत सुरक्षा SAML दावा समाप्ति मैं एसएएमएल दावा समाप्ति के साथ आवेदन सत्र की समाप्ति के साथ भ्रमित हो रहा हूं।

सरल शब्दों में, जब हमारे पास एक कंटेनर में तैनात एक एप्लीकेशन होता है, तो एक सत्र बनाया जाता है। इस सत्र की अवधि समाप्त होने पर आगे बढ़ते web.xml

<session-config> 
    <session-timeout>60</session-timeout> 
</session-config> 

में नीचे प्रविष्टि के साथ नियंत्रित किया जा सकता है, जब मैं SAML विस्तार के साथ वसंत सुरक्षा है, स्पष्ट रूप से एक ही सत्र अवधारणा लागू होता है। (यदि यह मायने रखता है तो मैं वाइल्डफ्लि 8.2 में एप्लिकेशन को तैनात कर रहा हूं)

आगे, जब एप्लिकेशन सत्र समाप्त हो जाता है, तो लॉगआउट व्यवहार स्थानीय लॉगआउट अवधारणा के बराबर लगता है।

अभी तक इतना अच्छा है। अब कहें कि SAML दावा 2 घंटे के लिए अच्छा है और उपयोगकर्ता 2 घंटे के लिए सक्रिय रूप से काम कर रहा है। उसके बाद के बाद के अनुरोध के साथ क्या होना चाहिए? क्या इसे आईडीपी में पुनः लॉगिन करना चाहिए? लेकिन, क्या यह उपयोगकर्ता के लिए असुविधाजनक नहीं होगा? यदि आवेदन समाप्ति समाप्ति के 2 घंटे बाद फिर से लॉग इन करने के लिए आईडीपी पर रीडायरेक्ट करता है, तो AJAX अनुरोधों को कैसे प्रबंधित किया जाना चाहिए?

यह करने के लिए the question here

Answer 1

स्प्रिंग SAML मुद्दों प्रमाणीकृत उपयोगकर्ताओं के लिए एक ExpiringUsernameAuthenticationToken संदर्भ में है। एक बार SAML Assertion उपयोगकर्ता को sessionNotOnOrAfter समय तक पहुंचने के लिए उपयोग किए जाने के बाद टोकन isAuthenticated() विधि में झूठी वापसी शुरू कर देता है।

यह व्यवहार जब अभिकथन समाप्त हो रहा है या मामला यह कभी नहीं करता है में nullSAMLAuthenticationProvider अधिभावी और विधि getExpirationDate(credential), जो समय के रिटर्न को बदलने के द्वारा निष्क्रिय किया जा सकता। आवेदन कंटेनर में कॉन्फ़िगर सत्र समाप्ति पर पूरी तरह भरोसा करेगा।

एक बार ExpiringUsernameAuthenticationToken समाप्त हो रहा है, स्प्रिंग सुरक्षा AuthenticationManager (<security:authentication-manager> तहत securityContext.xml में विन्यस्त) के लिए वर्तमान टोकन पारित करेंगे।

को संभालने में सक्षम अपने AuthenticationProvider को जोड़कर आप आगे क्या हो सकते हैं, इसे प्रभावित कर सकते हैं। अन्यथा ProviderNotFoundException या कुछ अन्य AuthenticationException जैसे BadCredentialsException (यदि आप एक ही समय में उपयोगकर्ता नाम/पासवर्ड प्रमाणीकरण का उपयोग कर रहे हैं) के साथ सिस्टम विफल रहता है।

अपवाद को बाद में ExceptionTranslationFilter द्वारा संभाला जाता है, जो कॉन्फ़िगर प्रमाणीकरण EntryPoint - उदाहरण के लिए नई प्रमाणीकरण प्रक्रिया शुरू करता है। SAMLEntryPoint जो या तो डिफ़ॉल्ट आईडीपी के साथ प्रमाणीकरण शुरू करता है या आईडीपी चयन पृष्ठ प्रदर्शित करता है। जैसा कि आप कहते हैं, प्रक्रिया अनिवार्य रूप से स्थानीय लॉगआउट भी करेगी।

डिफ़ॉल्ट रूप से सिस्टम सभी HTTP कॉल के लिए समान व्यवहार करता है - AJAX या नहीं। आप अपने एपीआई और सामान्य यूआरएल को अलग-अलग <security:http> तत्वों में विभाजित करके अलग-अलग व्यवहार को परिभाषित कर सकते हैं और प्रत्येक के लिए विभिन्न EntryPoints (इंटरफ़ेस AuthenticationEntryPoint) का उपयोग कर सकते हैं। उदाहरण के लिए Http403ForbiddenEntryPoint आपके AJAX कॉल के लिए उपयुक्त हो सकता है।