एंटरप्राइज़ एप्लिकेशन (ईएआई) में उपयोगकर्ता क्रेडेंशियल्स को स्टोर करने के लिए कहां?

Question

पृष्ठभूमि/प्रसंग

हम एक घटना अधिसूचना सेवा विकसित कर रहे हैं। उच्च स्तर पर आवेदन नीचे जैसा दिखता है:

हमारे विकास क्षेत्र में विजेट और ईएनएस शामिल है।

"ईएनएस" कुछ प्रकार की घटनाओं के लिए संग्रह के केंद्रीय बिंदु के रूप में कार्य करता है जो उपयोगकर्ताओं के लिए रूचि रखते हैं। कोई भी उपयोगकर्ता जो जानना चाहता है कि इस प्रकार की घटनाएं ENS, के साथ रजिस्ट्रार होती हैं जो क्रम में ईवेंट की पहचान करती है और सब्सक्रिप्शन के साथ सूचनाओं से मेल खाती है।

उपयोगकर्ता के लिए जो Subscibe करने के लिए एकीकृत आवेदन (db, पौधों का रस प्रणाली आदि)

घटनाओं के अनुक्रम का एक मान्य उपयोगकर्ता होना चाहिए चाहता है:

अब मेरी सवाल यह है:

उपयोगकर्ता डीबी, एसएपी आदि प्रमाण-पत्रों को संग्रहीत करने में सबसे अच्छे गुण क्या हैं।

EDIT उपयोगकर्ता को कितनी बार प्रमाणित किया जाना चाहिए? हर संदेश डिलीवर किया जाना चाहिए रहे हैं (@duffymo उल्लेख किया है, अगर मैं इस रणनीति का प्रयोग, यह स्रोत प्रणाली को प्रभावित करेगा)

अतिरिक्त जानकारी:? ENS वेब सेवाएं हैं।

ईएनएस एसएपी (और अन्य अनुप्रयोग) चुनाव करता है और यह वह जगह है जहां समस्या अधिक जटिल हो रही है। एसएपी में डेटा-स्तरीय प्राधिकरण है। इसलिए सभी उपयोगकर्ताओं को सभी घटनाओं/डेटा को देखने की अनुमति नहीं है।

यदि एसएपी ने उस उपयोगकर्ता की जानकारी के साथ डेटा को पुश किया है, जिसे देखने के लिए अधिकृत किया गया है, तो कोई समस्या नहीं है।

केस 1: समयबद्धक ENS

1. उपयोगकर्ता द्वारा की जा रही एक सदस्यता का सदस्य बनता। सदस्यता के समय, उपयोगकर्ता को एसएपी सिस्टम में उनके प्राधिकरण के लिए चेक किया जाता है। यदि ठीक है, तो उसे सदस्यता के लिए अनुमति दी जाएगी।
2. शेड्यूलर निर्धारित समय पर चलता है।
3. शेड्यूलर उन उपयोगकर्ताओं की पहचान करता है जिन्होंने सदस्यता ली है।
4. शेड्यूलर घटना होने पर पीओएलएल में उपयोगकर्ताओं के संग्रहित क्रेडेंशियल्स (ईएनएस में stroed) का उपयोग करता है।
5. यदि परिवर्तन हैं तो उपयोगकर्ताओं को सूचित करें।

यहाँ Disadvs:

• उपयोगकर्ता क्रेडेंशियल्स कहीं जमा हो जाती है बाहरी - सुरक्षा टीम इसे स्वीकार कर सकते हैं
• Reduntant दबाता है एक से अधिक उपयोगकर्ता सूचना के एक ही टुकड़े के लिए सदस्यता लिया है

केस 2: शेड्यूलर का उपयोग WIDGET द्वारा किया जाता है। उपयोगकर्ता क्रेडिट केवल स्थानीय मशीन में ही संग्रहीत किया जाएगा। Diadv: सदस्यता दैनिक है, और अगर उपयोगकर्ता प्रणाली/विजेट नहीं है

• हैं। उपयोगकर्ता अधिसूचनाओं को याद कर सकता है जो सप्ताहांत में कहा गया था। अगर अधिक एक से उपयोगकर्ता जानकारी के एक ही टुकड़े के लिए सदस्यता लिया है
• Reduntant सर्वर से पूरी करता है।

Answer 1

आमतौर पर यह वह एप्लिकेशन है जो डेटाबेस, एसएपी इत्यादि को प्रमाण पत्र दिया जाता है। व्यक्तिगत उपयोगकर्ताओं को एलडीएपी या डेटाबेस में प्रमाणित प्रमाणपत्र होंगे; प्रमाणीकरण और प्रमाणीकरण को एप्लिकेशन, ईएआई सर्वर, या साइटमाइंडर जैसे उपकरण द्वारा क्रॉस-कटिंग चिंता के रूप में संभाला जाएगा।

आने वाले अनुरोध को रोका और प्राधिकरण टोकन के लिए जाँच की जाएगी। यदि टोकन प्रकट नहीं होता है, तो प्रमाणीकरण और प्रमाणीकरण की जांच करें। यदि अनुमति है, तो प्राधिकरण टोकन बनाएं और इसे कैश करें।

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

मुझे केवल एक समस्या दिखाई देती है।

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

SAML जैसे मानकों पर एक नज़र अगर यह आपकी मदद कर सकता है देखने के लिए है।

कैशिंग समस्या घटनाओं और प्राधिकरण परिवर्तनों के बीच के बीच की तुलना के बीच तुलना पर निर्भर करती है। यदि घटनाओं के बीच का समय प्राधिकरण परिवर्तनों की तुलना में लंबा है, तो आपको हर बार जांचना होगा, क्योंकि आपके पास यह जानने का कोई तरीका नहीं है कि अंतिम घटना के बाद प्राधिकरण को रद्द कर दिया गया है या नहीं।

Answer 2

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

उपयोगकर्ता को हटाने वाले बाहरी सिस्टम पर मामले से निपटने के लिए आप एक और चीज का उपयोग कर सकते हैं, बाहरी सिस्टम से अधिसूचना संदेश उनके पास समाप्ति समय है। उदाहरण के लिए एक एसएपी अधिसूचना संदेश सृजन के समय के 2 घंटे बाद वैध हो सकता है। यदि उपयोगकर्ता को 2 घंटे में संदेश नहीं मिलता है तो संदेश हटा दिया जाता है। यदि आप एसएपी से अधिसूचना संदेशों के साथ संदेश समाप्ति को जोड़ते हैं कि कोई उपयोगकर्ता अब मान्य नहीं है तो आप जान सकते हैं कि एक समय सीमा है जिसके दौरान उपयोगकर्ता को अमान्य कर दिया जाएगा।

मुझे लगता है कि यदि आप उन तकनीकों के बारे में अधिक संदर्भ प्रदान करते हैं जिनका उपयोग आप ईएनएस को लागू करने के लिए कर रहे हैं तो हम आपको अधिक ठोस जवाब दे सकते हैं।

Answer 3

जिस तरह से मैंने इस पैटर्न को अक्सर लागू किया है, वह यह है कि प्रमाणीकरण बैक एंड की बजाय सदस्यता पर होता है। विषय पदानुक्रम बैक-एंड एप्लिकेशन के सुरक्षा मॉडल को प्रतिबिंबित करता है। यदि बैक-एंड का उत्पादन, डेली और किराने पर पूछताछ के लिए कार्य करता है, तो समान वर्गीकरण वाले विषय नोड मौजूद हैं। किराने के लिए बैक एंड सिस्टम में अधिकृत उपयोगकर्ता भी किराने के विषय के लिए अधिकृत हैं। बैक-एंड सिस्टम में प्राधिकरणों को समय-समय पर निर्यात किया जा सकता है (अक्सर यह रात है) और पब/उप ब्रोकर पर प्राधिकरण सेटिंग्स में परिवर्तित हो जाता है। एक कार्यान्वयन में मैंने बैक-एंड सिस्टम पर काम किया, एक सुरक्षित प्रशासनिक विषय पर पब/उप ब्रोकर में प्राधिकरण परिवर्तन प्रकाशित करेगा ताकि ग्राहक प्राधिकरण निकट-वास्तविक समय में अद्यतित रह सकें।

स्रोत प्रणाली पर वापस जाने वाले प्रमाण-पत्रों की धारणा पहली नज़र में सुरक्षित लगती है लेकिन गहन निरीक्षण पर कुछ समस्याएं होती हैं। सबसे पहले, आप इसे स्केल करने की योजना कैसे बनाते हैं? मैंने कभी भी एक सफल घटना अधिसूचना प्रणाली नहीं देखी है जिसे अत्यधिक पुन: उपयोग नहीं किया गया है। प्रत्येक बैक-एंड सिस्टम में प्रमाणीकरण, आमतौर पर अलग-अलग क्रेडेंशियल्स, अलग-अलग वैधता और कैशिंग आवश्यकताओं आदि के लिए अलग-अलग आवश्यकताएं होंगी। सिस्टम को कुछ बैक-एंड अनुप्रयोगों में वापस प्रमाण-पत्र प्रवाह करने के लिए सिस्टम बनाना एक बात है। इसे 10 या 20 के लिए करना एक दुःस्वप्न है।

मान लीजिए कि आपने ऊपर की समस्याओं को संबोधित किया है, तो अब आपने एक स्थान पर आधा बैक एंड एंटरप्राइज़ सिस्टम के लिए उपयोगकर्ता प्रमाण-पत्र कैश किए हैं। यदि वह एक केंद्रीय प्रणाली से समझौता किया गया है, तो यह सभी बैक-एंड सिस्टम हैं जिनसे यह बात करता है। वह केंद्रीय प्रणाली उद्यम में सबसे महत्वपूर्ण सुरक्षा केंद्र बिंदु बन गई है। इस समस्या को हल करने के लिए आवश्यक गंभीर सुरक्षा-फू महंगा है।

हां, यह पब/उप ब्रोकर दर्पण के विषय पेड़ और प्राधिकरणों को बैक एंड अनुप्रयोगों के सुरक्षा मॉडल को बनाने के लिए बट में दर्द है। लेकिन अंत में यह एक केंद्रीय ब्रोकर सेवा को डिजाइन करने के लिए पर्याप्त सुरक्षित (और कम महंगा) है जो सभी प्रमाण-पत्रों को स्टोर करने के लिए पर्याप्त है और ब्रोकर या स्रोत सिस्टम को प्रकाशित किए बिना स्रोत बैक-एंड सिस्टम में उन्हें सत्यापित करने में सक्षम है इसके लिए

Answer 4

LDAP भंडारण के लिए एक बेहतर विकल्प हो सकता है कि यह सुरक्षित और तेजी से और पोर्टेबल भी

* संपादित करें: अपने उद्यम एप्लिकेशन की पहुंच के अर्थ में पोर्टेबल।