मैंने उस मूल टिप्पणी को चुनने के लिए नहीं चुना है जिस तरह से इसे कहा गया था, लेकिन यह एक संभावित वैध मुद्दे की पहचान करता है ।
विशेष रूप से, जो चिंताएं अलग-अलग होती हैं, वे प्रमाणीकरण बनाम प्राधिकरण हैं ।
प्रमाणीकरण से तात्पर्य है लॉग इन करने और पहचान प्राप्त करने की प्रक्रिया से। यह है कि सिस्टम कैसे जानता है कि आप कौन हैं , और निजीकरण, वस्तु स्वामित्व आदि जैसी चीजों के लिए उपयोग किया जाता है।
प्राधिकरण का तात्पर्य है कि आपको क्या करने की अनुमति है , और यह (आम तौर पर) यह निर्धारित नहीं होता है कि आप कौन हैं । इसके बजाय, यह कुछ सुरक्षा नीतियों जैसे भूमिकाओं या अनुमतियों द्वारा निर्धारित किया जाता है, जो आपके नाम या ईमेल पते जैसी चीजों की परवाह नहीं करते हैं।
ये दोनों एक-दूसरे को ऑर्थोगोनली बदल सकते हैं। उदाहरण के लिए, आप OpenID / OpenAuth प्रदाताओं को जोड़कर प्रमाणीकरण मॉडल बदल सकते हैं। और आप एक नई भूमिका जोड़कर या RBAC से ABAC तक सुरक्षा नीति बदल सकते हैं।
यदि यह सब एक वर्ग या अमूर्त में चला जाता है, तो आपका सुरक्षा कोड, जो जोखिम शमन के लिए आपके सबसे महत्वपूर्ण साधनों में से एक है , विडंबना यह है कि उच्च जोखिम है।
मैंने उन प्रणालियों के साथ काम किया है जहां प्रमाणीकरण और प्राधिकरण बहुत कसकर युग्मित थे। एक प्रणाली में, दो समानांतर उपयोगकर्ता डेटाबेस थे, प्रत्येक एक प्रकार की "भूमिका" के लिए। जिस व्यक्ति या टीम ने इसे डिजाइन किया है, उसने स्पष्ट रूप से यह नहीं माना कि एक एकल भौतिक उपयोगकर्ता दोनों भूमिकाओं में हो सकता है, या यह कि कुछ कार्य हो सकते हैं जो कई भूमिकाओं के लिए सामान्य थे, या उपयोगकर्ता आईडी टकराव के साथ समस्या हो सकती है। यह एक अत्यंत चरम उदाहरण है, लेकिन इसके साथ काम करने के लिए यह अविश्वसनीय रूप से दर्दनाक था ।
Microsoft और Sun / Oracle (Java) सुरक्षा प्रिंसिपल के रूप में प्रमाणीकरण और प्राधिकरण जानकारी के एकत्रीकरण को संदर्भित करते हैं । यह सही नहीं है, लेकिन यह काफी अच्छी तरह से काम करता है। नेट में, उदाहरण के लिए, आपके पास है, जो समाहित - पूर्व एक जा रहा है नीति (प्राधिकरण) वस्तु, जबकि दूसरा एक है पहचान (प्रमाणीकरण)। आप यथोचित रूप से एक को दूसरे के अंदर रखने के निर्णय पर सवाल उठा सकते हैं , लेकिन महत्वपूर्ण बात यह है कि आपके द्वारा लिखा गया अधिकांश कोड केवल एक सार के लिए होगा, जिसका अर्थ है कि यह परीक्षण करना और रिफ्लेक्टर करना आसान है।IPrincipalIIdentity
एक User.IsAdminक्षेत्र में कुछ भी गलत नहीं है ... जब तक कि कोई User.Nameक्षेत्र भी नहीं है । यह इंगित करता है कि "उपयोगकर्ता" अवधारणा को ठीक से परिभाषित नहीं किया गया है और यह दुख की बात है, डेवलपर्स के बीच एक बहुत ही सामान्य गलती है जो सुरक्षा के बारे में कानों के पीछे थोड़ा गीला है। आमतौर पर, केवल एक चीज जिसे पहचान और नीति द्वारा साझा किया जाना चाहिए , वह यूजर आईडी है, जो संयोग से नहीं, बिल्कुल वैसा ही है, जिसे विंडोज और * निक्स दोनों सुरक्षा मॉडल में लागू किया जाता है।
यह रैपर ऑब्जेक्ट बनाने के लिए पूरी तरह से स्वीकार्य है जो पहचान और नीति दोनों को बाधित करता है। उदाहरण के लिए, यह एक डैशबोर्ड स्क्रीन के निर्माण की सुविधा प्रदान करेगा जहां आपको विभिन्न विजेट्स या लिंक के अलावा एक "हैलो" संदेश प्रदर्शित करने की आवश्यकता होती है जिसे वर्तमान उपयोगकर्ता को एक्सेस करने की अनुमति है। जब तक यह आवरण केवल पहचान और नीति की जानकारी को लपेटता है, और इसका दावा नहीं करता है। दूसरे शब्दों में, जब तक कि इसे एक मूल जड़ के रूप में प्रस्तुत नहीं किया जा रहा है ।
एक सरलीकृत सुरक्षा मॉडल हमेशा एक अच्छे विचार की तरह लगता है जब आप पहली बार एक नया आवेदन तैयार कर रहे हैं, क्योंकि YAGNI और वह सब, लेकिन यह लगभग हमेशा समाप्त होता है बाद में आपको काटने के लिए वापस आ जाता है, क्योंकि, आश्चर्य की बात है, नई सुविधाओं को जोड़ा जाता है!
इसलिए, यदि आप जानते हैं कि आपके लिए सबसे अच्छा क्या है, तो आप प्रमाणीकरण और प्राधिकरण जानकारी को अलग रखेंगे। यहां तक कि अगर "प्राधिकरण" अभी "IsAdmin" ध्वज के समान सरल है, तो आप अभी भी बेहतर होंगे यदि यह उसी वर्ग या तालिका का हिस्सा नहीं है जो प्रमाणीकरण सूचना के रूप में है, ताकि यदि और जब आपकी सुरक्षा नीति की आवश्यकता हो परिवर्तन, आपको अपने प्रमाणीकरण प्रणालियों पर पुनर्निर्माण सर्जरी करने की आवश्यकता नहीं है जो पहले से ही ठीक है।