ASP.NET MVC में भूमिका-आधारित अभिगम नियंत्रण (RBAC) बनाम दावा-आधारित अभिगम नियंत्रण (CBAC)

Question

का उपयोग करने का मुख्य लाभ क्या हैं CBAC बनाम RBAC ? सीबीएसी का उपयोग करना कब बेहतर है और आरबीएसी का उपयोग करना कब बेहतर है?

मैं CBAC मॉडल की सामान्य अवधारणाओं को समझने की कोशिश कर रहा हूं, लेकिन सामान्य विचार अभी भी मेरे लिए स्पष्ट नहीं है।

Comments

ये अवधारणाएँ अभी भी मेरे लिए बहुत अस्पष्ट हैं। वे भी ऐसा ही करने लगते हैं। एक मूल्य के साथ एक भूमिका है?

— Zapnologica

Answer 1

मैं यह दिखाने की कोशिश करूंगा कि आप ASP.NET MVC प्रसंग में क्लेम बेस्ड एक्सेस कंट्रोल से कैसे लाभान्वित हो सकते हैं।

जब आप रोल आधारित प्रमाणीकरण का उपयोग कर रहे हैं, यदि आपके पास ग्राहक बनाने के लिए कोई कार्रवाई है और आप चाहते हैं कि जो लोग 'बिक्री' की भूमिका में हैं, वे ऐसा करने में सक्षम हों, तो आप इस तरह कोड लिखते हैं:

[Authorize(Roles="Sale")]
public ActionResult CreateCustomer()
{
    return View();
}

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

[Authorize(Roles = "Sale", "Marketing")]
public ActionResult CreateCustomer()
{
    return View();
}

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

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

अनुमति आधारित अभिगम नियंत्रण विभिन्न उपयोगकर्ताओं को विभिन्न अनुमतियों को निर्दिष्ट करने और जाँचने का एक तरीका है कि क्या किसी उपयोगकर्ता के पास रन टाइम में कोड से किसी कार्रवाई को निष्पादित करने की अनुमति है। जब आप विभिन्न उपयोगकर्ताओं को विभिन्न अनुमतियाँ प्रदान करते हैं, तो आपको एहसास होता है कि आपको कुछ उपयोगकर्ताओं को कुछ कोड निष्पादित करने की अनुमति देने की आवश्यकता है यदि उपयोगकर्ता के पास "फेसबुक उपयोगकर्ता", "लंबे समय उपयोगकर्ता" आदि जैसी कुछ संपत्ति है तो मुझे एक उदाहरण दें। यदि आप उपयोगकर्ता को फेसबुक का उपयोग करने में लॉग इन करते हैं, तो आप किसी विशिष्ट पृष्ठ तक पहुँच की अनुमति देना चाहते हैं। अब, क्या आप उस उपयोगकर्ता के लिए एक अनुमति 'फेसबुक' बनाएंगे? नहीं, 'फेसबुक' एक अनुमति की तरह नहीं है। क्या यह ? बल्कि यह एक दावे की तरह लगता है। उसी समय, दावे क्लेम की तरह लग सकते हैं !! इसलिए, दावों की जांच करना और पहुंच की अनुमति देना बेहतर है।

अब, दावा आधारित अभिगम नियंत्रण के ठोस उदाहरण पर वापस जाने देता है।

आप कुछ दावों को इस तरह परिभाषित कर सकते हैं:

"कैनक्रिएट कस्टूमर", "कैनडेलीट कस्टूमर", "कैनडिटक्युलेटर" .. आदि।

अब, आप अपनी कार्य विधि को इस तरह से सजा सकते हैं:

        [ClaimAuthorize(Permission="CanCreateCustomer")]
        public ActionResult CreateCustomer()
        {
            return View();
        }

(कृपया ध्यान दें, [ClaimAuthorize (अनुमति = "CanCreateCustomer")] MVC वर्ग के पुस्तकालय में नहीं बनाया जा सकता है, मैं सिर्फ एक उदाहरण के रूप में दिखा रहा हूं, आप कुछ क्लास लाइब्रेरी का उपयोग कर सकते हैं, जिसमें ऐसी विशेषता वर्ग परिभाषा है

अब, आप देख सकते हैं कि, CreateCustomer एक्शन विधि को हमेशा 'CanCreateCustomer' की अनुमति की आवश्यकता होगी और यह कभी नहीं बदलेगी या शायद ही कभी बदलेगी। इसलिए, अपने डेटाबेस में, आप अनुमतियों (दावों) और उपयोगकर्ता-अनुमति संबंध की एक तालिका बनाते हैं। अपने व्यवस्थापक पैनल से, आप प्रत्येक उपयोगकर्ता के लिए अनुमति (दावा) निर्धारित कर सकते हैं जो क्या कर सकता है। आप किसी को भी पसंद कर सकते हैं और केवल अनुमति प्राप्त उपयोगकर्ता के लिए 'CanCreateCustomer' की अनुमति (दावा) असाइन कर सकते हैं और अनुमति उपयोगकर्ता केवल ग्राहक और कुछ भी नहीं बनाने में सक्षम हो जाएगा (जब तक आप एक ही उपयोगकर्ता को अन्य अनुमतियाँ असाइन नहीं करते)।

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

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

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

Comments

मैं इस बारे में उलझन में हूं कि रोल्स फैक्टर दावों में कैसे है - दावों-आधारित सिस्टम भूमिकाओं में नहीं हैं मूल रूप से दावों का एक समूह है ताकि आप सामान को असाइन कर सकें? उदाहरण के लिए, आप कह सकते हैं कि बॉब मार्केटिंग में भूमिका में है और मार्केटिंग में सभी का दावा हैCanCreateCustomer, CanViewAdCampaigns

— जॉर्ज माउर

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

— लियोन कलनेंस

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

— hemp

मान लीजिए कि मैं इसे इस तरह से चाहता हूं: 1) एक "अनुमति" एक साधारण कार्रवाई करने का अधिकार है, जैसे "ग्राहक बनाएं"। अनुमति का नाम "कैन" से शुरू होता है - CanCreateCustomer। ऐप के सोर्स कोड में अनुमतियों के नाम हार्डकोड किए गए हैं। 2) एक उपयोगकर्ता को अनुमतियों का एक सेट सौंपा जा सकता है - लेकिन सीधे नहीं। उपयोगकर्ता केवल भूमिकाओं के माध्यम से अनुमति प्राप्त करता है। 3) एक भूमिका अनुमतियों का एक सेट है, अधिक कुछ नहीं। कुछ अंतिम उपयोगकर्ता (प्रवेशकर्ता) मनमाने ढंग से सेट ओडी अनुमतियों (निर्धारित सूची से चुने गए) के साथ गतिशील रूप से नई कस्टम भूमिकाएँ बना सकते हैं। सवाल यह है कि क्या मैं दावा-आधारित मॉडल के साथ इसे पसंद कर सकता हूं?

— दिमित्री अरस्तोव 2

Microsoft दस्तावेज़ीकरण कहता है: एक दावा नाम मान युग्म है जो यह दर्शाता है कि विषय क्या है, न कि विषय क्या कर सकता है।

— कोडिंगसॉफ्ट

Answer 2

मैंने अब कई बार सुरक्षा मॉडल लागू किए हैं और मुझे इन अवधारणाओं के आसपास अपना सिर भी लपेटना पड़ा है। कई बार ऐसा करने के बाद, यहाँ इन अवधारणाओं के बारे में मेरी समझ है।

रोल्स क्या हैं

भूमिका = उपयोगकर्ताओं और अनुमतियों का मिलन ।

एक तरफ, एक भूमिका अनुमतियों का एक संग्रह है। मैं इसे परमिशन प्रोफाइल कहना पसंद करता हूं। जब एक भूमिका को परिभाषित करते हैं तो आप मूल रूप से उस भूमिका में अनुमतियों का एक गुच्छा जोड़ते हैं तो इस अर्थ में कि भूमिका एक अनुमति प्रोफ़ाइल है।

दूसरी ओर, एक भूमिका भी उपयोगकर्ताओं का एक संग्रह है। अगर मैं बॉब और ऐलिस को रोल "मैनेजर्स" में जोड़ता हूं तो "मैनेजर्स" में अब एक ग्रुप की तरह दो यूजर्स का कलेक्शन है।

सच्चाई यह है कि एक भूमिका उपयोगकर्ताओं का एक संग्रह है और अनुमतियों का एक संग्रह एक साथ रखा जाता है। नेत्रहीन रूप से इसे वेन आरेख के रूप में देखा जा सकता है।

एक समूह क्या है

समूह = उपयोगकर्ताओं का संग्रह

एक "समूह" कड़ाई से उपयोगकर्ताओं का एक संग्रह है। एक समूह और एक भूमिका के बीच का अंतर यह है कि एक भूमिका में अनुमतियों का एक संग्रह भी होता है लेकिन एक समूह में केवल उपयोगकर्ताओं का एक संग्रह होता है।

परमिशन क्या है

अनुमति = कोई विषय क्या कर सकता है

परमिशन सेट क्या है

अनुमति सेट = अनुमतियों का एक संग्रह

एक मजबूत RBAC प्रणाली में, अनुमतियाँ भी उपयोगकर्ताओं की तरह समूहीकृत की जा सकती हैं। जबकि समूह केवल उपयोगकर्ताओं का एक संग्रह है, एक अनुमति सेट केवल अनुमतियों का एक संग्रह है। यह एक व्यवस्थापक को एक समय में अनुमतियों के पूरे संग्रह को रोल्स में जोड़ने की अनुमति देता है।

कैसे उपयोगकर्ता, समूह, भूमिकाएँ और अनुमतियाँ एक साथ आती हैं

एक मजबूत आरबीएसी प्रणाली में, उपयोगकर्ताओं को एक भूमिका में जोड़ा जा सकता है बनाने के लिए व्यक्तिगत रूप से भूमिका या समूह में उपयोगकर्ताओं का संग्रह एक भूमिका में जोड़ा जा सकता है भूमिका में एक समय में उपयोगकर्ताओं के संग्रह को जोड़ने के लिए। किसी भी तरह से, भूमिका को उपयोगकर्ताओं के व्यक्तिगत रूप से जोड़े जाने से या समूह में जोड़कर या भूमिका में उपयोगकर्ताओं और समूहों का मिश्रण जोड़कर उपयोगकर्ताओं के अपने संग्रह को प्राप्त किया जाता है। अनुमतियाँ उसी तरह से सोची जा सकती हैं।

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

रोल्स का पूरा उद्देश्य उपयोगकर्ताओं को अनुमतियों से शादी करना है। इसलिए, एक भूमिका उपयोगकर्ताओं और अनुमतियों का संघ है।

दावे क्या हैं?

दावा = क्या विषय है "

दावे नहीं अनुमतियाँ हैं। जैसा कि पिछले उत्तरों में बताया गया है, एक दावा वह है जो एक विषय "है" वह नहीं जो एक विषय "कर सकता है"।

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

क्लेम का उपयोग कब करें

मैंने दावा किया है कि जब एक उपयोगकर्ता को एक भूमिका में जोड़ा नहीं जा सकता है या निर्णय उपयोगकर्ता की अनुमति के आधार पर निर्णय पर आधारित नहीं हो सकता है, तो उपयोगी होने का दावा किया जाता है। फेसबुक यूजर का उदाहरण इसका कारण बनता है। एक फेसबुक उपयोगकर्ता कोई नहीं हो सकता है जो "भूमिका" में जोड़ा जाता है ... वे फेसबुक के माध्यम से प्रमाणित कुछ विज़िटर हैं। यद्यपि यह आरबीएसी में बड़े करीने से फिट नहीं है, यह एक प्राधिकरण निर्णय लेने के लिए जानकारी का एक टुकड़ा है।

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

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

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

यदि किसी भी कारण से कुछ कमरों को रोल द्वारा जोड़ने / हटाने की आवश्यकता होती है, तो यह आरबीएसी का उपयोग करके किया जा सकता है, लेकिन यह एक क्लेम के लिए अच्छा फिट नहीं है।

सॉफ्टवेयर में अनुमतियाँ

आवेदन में कोडिंग रोल्स एक बुरा विचार है। यह हार्ड एप्लीकेशन में भूमिका के उद्देश्य को कोड करता है। एप्लिकेशन के पास क्या होना चाहिए, यह केवल अनुमतियाँ हैं जो फ़ीचर फ्लैग की तरह कार्य करती हैं। जहां सुविधा फ़्लैग को कॉन्फ़िगरेशन द्वारा पहुंच योग्य बनाया जाता है, अनुमतियाँ उपयोगकर्ता सुरक्षा संदर्भ द्वारा सुलभ बनाई जाती हैं, जो सभी Roles उपयोगकर्ता द्वारा एकत्र किए गए अनुमतियों के DISTCT संग्रह द्वारा प्राप्त की जाती हैं, जिसे मैं "प्रभावी" कहता हूं। आवेदन केवल एक मेनू प्रस्तुत करना चाहिएसुविधाओं / कार्यों के लिए संभावित अनुमतियाँ। RBAC प्रणाली को उन अनुमतियों को रोल के माध्यम से उपयोगकर्ताओं से शादी करने का काम करना चाहिए। इस तरह, रोल्स की कोई हार्ड कोडिंग नहीं होती है और केवल एक ही बार जब कोई बदलाव होता है तो उसे हटा दिया जाता है या एक नया जोड़ा जाता है। एक बार एक अनुमति सॉफ्टवेयर में जोड़ा जाता है इसे कभी नहीं बदला जाना चाहिए। इसे केवल तब ही हटाया जाना चाहिए जब आवश्यक हो (अर्थात जब एक नए संस्करण में कोई सुविधा बंद हो जाती है) और केवल नए जोड़े जा सकते हैं।

एक अंतिम नोट।

अनुदान बनाम इनकार

एक मजबूत RBAC प्रणाली और यहां तक ​​कि एक CBAC प्रणाली को अनुदान और इनकार के बीच अंतर करना चाहिए।

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

यह व्यवस्थापकों को किसी विषय के अंतिम अनुमतियों को "ट्विक" करने की अनुमति देता है। यह सर्वोत्तम है यदि अनुमतियाँ सीधे उपयोगकर्ताओं को भी जोड़ी जा सकती हैं। इस तरह, आप एक उपयोगकर्ता को प्रबंधक भूमिका में जोड़ सकते हैं और उन्हें सब कुछ प्राप्त हो सकता है, लेकिन शायद आप लेडी के टॉयलेट तक पहुँच प्राप्त करना चाहते हैं क्योंकि उपयोगकर्ता एक पुरुष है। तो आप पुरुष उपयोगकर्ता को प्रबंधक भूमिका में जोड़ते हैं, और DENY के साथ उपयोगकर्ता ऑब्जेक्ट के लिए एक अनुमति जोड़ते हैं ताकि यह केवल उस लेडी के कमरे तक पहुंच से दूर हो जाए।

वास्तव में, यह एक दावे के लिए एक अच्छा उम्मीदवार होगा। यदि उपयोगकर्ता के पास एक दावा "लिंग = पुरुष" है, तो प्रबंधक भूमिका में होने के कारण सभी कमरों तक पहुंच मिलती है लेकिन लेडी के टॉयलेट में भी क्लेम लिंग = महिला की आवश्यकता होती है और पुरुषों के टॉयलेट के लिए क्लेम लिंग = पुरुष की आवश्यकता होती है। इस तरह से किसी को पुरुष उपयोगकर्ताओं के लिए DENY अनुमति को कॉन्फ़िगर नहीं करना होगा क्योंकि क्लेम प्रवर्तन एक एकल लेखक नियम के साथ सभी के लिए इसका ख्याल रखता है। हालाँकि, यह किसी भी तरह से किया जा सकता है।

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

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

आशा है कि ये आपकी मदद करेगा।

यह आरबीएसी डिस्क्राइब्ड एबव का डायग्राम है

7 अप्रैल, 2019 को अपडेट करें @Brent (साभार) के फीडबैक के आधार पर ... पिछले उत्तरों के अनावश्यक संदर्भ हटा दिए और @CodingSoft द्वारा उपलब्ध कराए गए "नाइट क्लब" रूपक के मूल आधार को स्पष्ट कर दिया, ताकि यह जवाब बिना समझ में आए अन्य उत्तर पढ़ने के लिए।

Comments

यह एक महान व्याख्या है जिसे ऊपर तक उखाड़ा जाना चाहिए, उदाहरण और आरेख को जोड़ने के लिए धन्यवाद।

— ऑप्टिमा

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

— ब्रेंट

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

— रिकार्डो

सहमत, यह शीर्ष उत्तर होना चाहिए। अन्य अच्छे उत्तर हैं, लेकिन यह स्पष्ट और सबसे व्यापक और सटीक है।

— मतिजा हान

यह बहुत ही सामान्य भाषा में भयानक और समझाया गया है - धन्यवाद

— खिलौना

Answer 3

मैं इमरान के जवाब से पूरी तरह सहमत नहीं हूं

[Authorize(Roles="Sale")]

भोला है

सवाल यह है कि कैसे

  [Authorize(Roles="CustomerCreator")]

से अलग है

 [ClaimAuthorize(Permission="CanCreateCustomer")]

यदि दोनों समान रूप से अच्छे हैं, तो हमें दावे की आवश्यकता क्यों है?

मुझे लगता है क्योंकि

भूमिका की तुलना में दावा अवधारणा अधिक सामान्य है

ऊपर के उदाहरण के संदर्भ में हम कह सकते हैं कि "CustomerCreator" "Asp.NETroleProvider" द्वारा प्रदान की गई "भूमिका" प्रकार का एक दावा है

दावों के अतिरिक्त उदाहरण।

1. "AAA" "MYExamSite.com" द्वारा प्रदान किए गए "MYExamSite.Score" प्रकार का दावा है

2. "गोल्ड" "MYGYMApp" द्वारा प्रदान किए गए "MYGYM.Membershiptype" प्रकार का दावा है

Comments

मुझे लगता है कि इस उत्तर का मूल्य है क्योंकि यह एक दावे और इसकी समकक्ष भूमिका के बीच मूलभूत अंतर को संबोधित करता है, बजाय एक परिदृश्य का वर्णन करने के जो प्रभावी रूप से एक दावे या भूमिका-आधारित प्राधिकरण मॉडल का उपयोग करके लागू किया जा सकता है। +1

— कैटस्टेवेंस

मैंने अपने उत्तर पर एक टिप्पणी पोस्ट की है। मैंने कहा, यह इस बात पर निर्भर करता है कि आप अपने संगठन में "भूमिका" को कैसे परिभाषित करते हैं। आप एक भूमिका को परिभाषित कर सकते हैं जो अनुमति / या दावे की तरह लगती है। आप एक ही लक्ष्य को प्राप्त करना बंद नहीं करेंगे। रोल का अर्थ आमतौर पर "नियुक्ति" होता है; शब्दों का उपयोग कैसे किया जाता है। अंतर अवधारणा में है, बल्कि तकनीक का है। यदि आप [अधिकृत (Roles = "CustomerCreator")] का उपयोग कर रहे हैं, तो यह सार अर्थ में CBAC के समान होगा। बहस इस बात की है कि क्या आपको अपने सुरक्षा मॉडल में अपॉइंटमेंट्स या माइको अनुमतियाँ बनानी चाहिए। दावा केवल अनुमतियों के बारे में नहीं है, यह अधिक प्रदान करता है।

— इमरान हुसैन

MSSQL में भूमिकाएँ इसी प्रकार की जाती हैं। इसमें DBDataReader और DBDataWriter नहीं MyAppDB और HisAppDB है।

— बेहारोज़

भूमिकाओं का अर्थ नियुक्ति कैसे होता है? RBAC में भूमिकाओं को अनुमतियों के साथ सौंपा गया है।

— Wouter

Answer 4

स्वीकृत उत्तर रोल्स को एक कुंद वस्तु के रूप में प्रदर्शित करता है और एक लचीले उपकरण के रूप में दावा करता है, लेकिन अन्यथा उन्हें लगभग समान प्रतीत होता है। दुर्भाग्य से, यह स्थिति दावों की अवधारणा के प्रति असंतोष करती है और मौलिक रूप से उनके उद्देश्य की थोड़ी सी गलतफहमी को दर्शा सकती है।

रोल्स मौजूद हैं और केवल एक अंतर्निहित दायरे के भीतर समझ में आता है। आम तौर पर यह एक अनुप्रयोग या संगठनात्मक क्षेत्र (यानी भूमिका = प्रशासक) है। दूसरी ओर, दावे किसी के द्वारा भी किए जा सकते हैं। उदाहरण के लिए, Google प्रमाणीकरण उपयोगकर्ता के "ईमेल" सहित दावों का उत्पादन कर सकता है, इस प्रकार उस ईमेल को एक पहचान में संलग्न करता है। Google दावा करता है, एप्लिकेशन चुनता है कि उस दावे को समझना और स्वीकार करना है या नहीं। एप्लिकेशन स्वयं बाद में "Google" के मान के साथ "प्रमाणीकरणमिथोड" (ASP.NET MVC कोर पहचान करता है) नामक दावा संलग्न कर सकता है। प्रत्येक दावे में एक गुंजाइश शामिल होती है ताकि यह पहचानना संभव हो कि क्या किसी दावे का बाहरी रूप से अर्थ है, या दोनों (या आवश्यकता के अनुसार अधिक महीन बीज)।

मुख्य बिंदु यह है कि सभी दावे स्पष्ट रूप से एक पहचान से जुड़े होते हैं और एक स्पष्ट दायरे को शामिल करते हैं। उन दावों को प्राधिकरण के लिए इस्तेमाल किया जा सकता है - और ASP.NET MVC अधिकृत विशेषता के माध्यम से उस के लिए समर्थन प्रदान करता है, लेकिन यह केवल या अनिवार्य रूप से दावों के लिए प्राथमिक उद्देश्य भी नहीं है। यह निश्चित रूप से इसे रोल्स से अलग नहीं करता है, जिसका उपयोग स्थानीय रूप से स्कोप किए गए प्राधिकरण के लिए बिल्कुल उसी तरीके से किया जा सकता है।

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

Comments

अच्छा जवाब ... मुझे लगता है कि मैं आपको समझता हूं ..., लेकिन यह स्पष्ट होगा कि क्या आप कुछ ठोस उदाहरण प्रदान कर सकते हैं (संभवतः एएसपी एमवीसी के संदर्भ में) ... जवाब बहुत ही सार है, मैं अपने सिर को लपेटने में कठिन समय ले रहा हूं। इसके आसपास।

— रोजी कासिम

दूसरे पैराग्राफ में ASP.NET MVC कोर पहचान और Google प्रमाणीकरण से संबंधित एक ठोस उदाहरण शामिल है। ऐसा लगता है एक अधिक विस्तृत तरह कोर के नए मॉडल में मदद मिलेगी की पैदल दूरी पर होना - के लिए है कि मैं इस लेख की सिफारिश: andrewlock.net/introduction-to-authentication-with-asp-net-core

— भांग

सबसे अच्छा जवाब IMHO

— mrmashal

Answer 5

अधिक मोटे तौर पर, आपको विशेषता-आधारित अभिगम नियंत्रण (ABAC) पर विचार करना चाहिए। RBAC और ABAC दोनों NIST, राष्ट्रीय मानक और प्रौद्योगिकी संस्थान द्वारा परिभाषित अवधारणाएं हैं। दूसरी ओर, CBAC, Microsoft द्वारा धक्का दिया गया एक मॉडल है जो ABAC से काफी मिलता-जुलता है।

यहाँ और पढ़ें:

• भूमिका आधारित अभिगम नियंत्रण NIST पृष्ठ
• विशेषता-आधारित अभिगम नियंत्रण NIST पृष्ठ

Comments

जबकि विशेषता-आधारित अभिगम नियंत्रण का उपयोग करने की सिफारिश महान है। MVC / WebAPI स्टैक में इन्हें लागू करने की सामान्य / सर्वोत्तम प्रथाओं के लिंक अच्छे होंगे। धन्यवाद

— Itanex

Answer 6

RBAC और CBAC के बीच मूलभूत बात यह है कि:

आरबीएसी : एक उपयोगकर्ता को एक भूमिका सौंपी जानी चाहिए ताकि वह कार्रवाई करने के लिए अधिकृत हो सके।

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

इसके अलावा कि दावों को जारी करने वाली प्राधिकारी सेवाओं (सुरक्षा सेवा टोकन एसटीएस) द्वारा जारी किया जाता है जो आपके आवेदन (भरोसा पार्टी) द्वारा विश्वसनीय है।

Answer 7

भूमिका केवल एक प्रकार का दावा है। उस तरह से, कई अन्य प्रकार के दावे हो सकते हैं, उदाहरण के लिए उपयोगकर्ता नाम दावा प्रकार में से एक है

Answer 8

पहले यह विश्लेषण करना महत्वपूर्ण है कि किस विधि का निर्णय लेने से पहले प्रमाणीकरण के लिए क्या आवश्यक है। नीचे Microsoft दस्तावेज़ीकरण से, यह कहता है "एक दावा यह नहीं है कि विषय क्या कर सकता है। उदाहरण के लिए, आपके पास एक ड्राइविंग लाइसेंस हो सकता है, जो स्थानीय ड्राइविंग लाइसेंस प्राधिकरण द्वारा जारी किया गया हो। आपके ड्राइवर के लाइसेंस में आपकी जन्म तिथि है। इस में। दावा नाम DateOfBirth होगा, दावा मूल्य आपकी जन्म तिथि होगी, उदाहरण के लिए 8 जून 1970 और जारीकर्ता ड्राइविंग लाइसेंस प्राधिकरण होगा। दावा आधारित प्राधिकरण, अपने सरलतम रूप से, एक दावे के मूल्य की जांच करता है और पहुंच की अनुमति देता है। उस मान के आधार पर एक संसाधन। उदाहरण के लिए, यदि आप एक नाइट क्लब तक पहुंच चाहते हैं, तो प्राधिकरण प्रक्रिया हो सकती है: 6 "

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

भूमिका आधारित प्राधिकरण https://docs.microsoft.com/en-us/aspnet/core/security/authorization/roles 10/14/2016 जब कोई पहचान बनाई जाती है तो वह एक या अधिक भूमिकाओं से संबंधित हो सकती है। उदाहरण के लिए, ट्रेसी का संबंध प्रशासक और उपयोगकर्ता की भूमिका से हो सकता है, जबकि स्कॉट केवल उपयोगकर्ता की भूमिका का हो सकता है। इन भूमिकाओं को कैसे बनाया और प्रबंधित किया जाता है, यह प्राधिकरण प्रक्रिया के समर्थन स्टोर पर निर्भर करता है। ClaimsPrincipal class पर IsInRole पद्धति के माध्यम से डेवलपर को रोल्स उजागर किए जाते हैं।

दावे-आधारित प्राधिकरण https://docs.microsoft.com/en-us/aspnet/core/security/authorization/chims 10/14/2016 जब एक पहचान बनाई जाती है, तो उसे एक विश्वसनीय पार्टी द्वारा जारी किए गए एक या अधिक दावों को सौंपा जा सकता है। एक दावा नाम मान युग्म है जो विषय का प्रतिनिधित्व करता है, न कि विषय क्या कर सकता है। उदाहरण के लिए, आपके पास ड्राइविंग लाइसेंस हो सकता है, जो स्थानीय ड्राइविंग लाइसेंस प्राधिकरण द्वारा जारी किया गया हो। आपके ड्राइवर के लाइसेंस में आपकी जन्म तिथि है। इस स्थिति में दावा नाम DateOfBirth होगा, दावा मूल्य आपकी जन्म तिथि होगी, उदाहरण के लिए 8 जून 1970 और जारीकर्ता ड्राइविंग लाइसेंस प्राधिकरण होगा। दावा आधारित प्राधिकरण, अपने सरलतम पर, एक दावे के मूल्य की जांच करता है और उस मूल्य के आधार पर एक संसाधन तक पहुंच की अनुमति देता है। उदाहरण के लिए यदि आप नाइट क्लब तक पहुँच चाहते हैं तो प्राधिकरण प्रक्रिया हो सकती है:

दरवाजा सुरक्षा अधिकारी आपकी जन्मतिथि के मूल्य का मूल्यांकन करेगा और आपको पहुँच प्रदान करने से पहले वे जारीकर्ता (ड्राइविंग लाइसेंस प्राधिकरण) पर भरोसा करेंगे।

एक पहचान में कई मूल्यों के साथ कई दावे हो सकते हैं और एक ही प्रकार के कई दावे शामिल हो सकते हैं।

Answer 9

दावों के ढंग से भूमिकाओं का प्रबंधन करना भी संभव है।

एक व्यावसायिक भूमिका को प्रतिबिंबित करने वाली प्राधिकरण भूमिकाएं बनाने के बजाय, ऐसी भूमिकाएं बनाएं, जो एक्शन भूमिकाओं को दर्शाती हैं, जैसे क्रिएट कस्टूमर, एडिटकास्टर, डिलीट कस्टूमर। आवश्यकतानुसार विधियों का उल्लेख करें।

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

आप व्यावसायिक भूमिका को ओवरराइड भी कर सकते हैं और किसी व्यक्ति को सीधे एक्शन भूमिका में जोड़ सकते हैं।

क्योंकि आप पहले से ही जो काम करते हैं, उसके शीर्ष पर आप मौजूदा प्राधिकरण प्रक्रिया को पूर्ववत नहीं करते हैं। इस दृष्टिकोण को लागू करने के लिए आपको केवल कुछ और तालिकाओं की आवश्यकता है

Answer 10

मुझे लगता है कि इस सवाल का जवाब डेटाबेस से दिया जा सकता है। यदि आपने देखा कि कैसे इस आरोपण में शामिल तालिकाओं में आपको निम्नलिखित मिलेंगे

1. AspNetUsers: प्रत्येक उपयोगकर्ता के पास सभी उपयोगकर्ताओं द्वारा आवश्यक सभी विशेषताओं जैसे ईमेल, एड्रेस फोन, पासवर्ड ..... के साथ एक पंक्ति है।
2. AspNetRoles; GM, CTO, HRM, ADMIN, EMP जैसी एप्लिकेशन आवश्यकताओं के अनुसार विभिन्न भूमिकाओं को परिभाषित करता है। प्रत्येक भूमिका को परिभाषित करता है कि आवेदन की जरूरत के अनुसार है।
3. AspNetUserRoles: प्रत्येक पंक्ति AspNetUser और AspNetRoles को लिंक करती है और एक उपयोगकर्ता और कई भूमिकाओं के बीच प्रभावी रूप से लिंक करती है।
4. AspNetUserClaims: प्रत्येक पंक्ति में AspNetUsers और एक प्रकार और मूल्य की कुंजी है। इसलिए प्रभावी रूप से प्रत्येक उपयोगकर्ता के लिए एक विशेषता जोड़ें जो रन टाइम पर जोड़ा / हटाया जा सकता है।

विशिष्ट आवश्यकताओं से मेल खाने के लिए इस तालिकाओं के उपयोग को उपयोगकर्ता / एप्लिकेशन जीवन के समय के एक क्षण में बदल दिया जा सकता है।

"क्रय प्रबंधक" (पीएम) के शुरुआती चरण पर विचार करें, हमारे पास तीन दृष्टिकोण हो सकते हैं

1. आवेदन खरीदने के लिए 'PM' के अधिकार के लिए एक पंक्ति के साथ AspNetUserRoles को आबाद करता है। किसी भी राशि के साथ क्रय आदेश जारी करने के लिए, उपयोगकर्ता को केवल "PM" भूमिका की आवश्यकता होती है।

2. आवेदन AspNetUserRoles को खरीदने के लिए 'PM' के अधिकार के लिए एक पंक्ति के साथ AspNetUserRoles को पॉप्युलेट करता है, और TYPE 'क्रय राशि' प्रकार और "<1000" मान का दावा करता है ताकि राशि सीमा निर्धारित की जा सके। क्रय आदेश जारी करने के लिए, उपयोगकर्ता के पास 'PM'and' की आवश्यकता होती है और आदेश राशि, दावे के प्रकार 'क्रय राशि' से कम होनी चाहिए।

3. अनुप्रयोग TYPE 'क्रय राशि' प्रकार और "<1000" मान के दावे के साथ AspNetUserClaims को आबाद करता है। कोई भी उपयोगकर्ता क्रय आदेश जारी कर सकता है, यह राशि इस उपयोगकर्ता के लिए TYPE 'क्रय राशि' के दावे के मूल्य से कम है।

जैसा कि यह देखा जा सकता है, भूमिका आधारित कठोर अधिकारों का मोटे अनाज है जो सिस्टम प्रबंधन के दृष्टिकोण से अनुप्रयोग उपयोगकर्ता के जीवन को सरल करेगा। हालाँकि, यह व्यावसायिक आवश्यकताओं के दृष्टिकोण से उपयोगकर्ता क्षमताओं को सीमित करेगा। दूसरी ओर आधारित दावा बहुत महीन अधिकार है जिसे प्रत्येक उपयोगकर्ता को सौंपा जाना आवश्यक है। दावा आधारित व्यवसाय को बहुत सीमा तक धकेल देगा, हालांकि सिस्टम प्रबंधन को बहुत जटिल बना देगा।

Answer 11

भूमिका आधारित अभिगम नियंत्रण (RBAC)

आपके संगठन में, आपकी निम्न भूमिकाएँ हो सकती हैं

कर्मचारी

मैनेजर

मानव संसाधन

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

भूमिका-आधारित प्राधिकरण को कार्यान्वित करने के लिए ASP.NET Core में, हम Roles पैरामीटर के साथ अधिकृत विशेषता का उपयोग करते हैं।

[Authorize(Roles = "Admin")]
public class AdministrationController : Controller
{
}

दावा आधारित अभिगम नियंत्रण (CBAC)

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

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

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

[Authorize(Policy = "DeleteRolePolicy")]
public async Task<IActionResult> DeleteRole(string id)
{
}