एक्सेस कंट्रोल - आरबीएसी एक पदानुक्रमित उपयोगकर्ता प्रबंधन प्रणाली में लागू करने लायक है?

Question

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

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

मैं के सभी कल्पना से ऊपर भी समस्याग्रस्त आगे डिजाइन और अनुमतियाँ भूमिकाओं के बिना इस्तेमाल किया गया है, तो ("भूमिकाओं" RBAC शब्दावली में अनुमतियों के संग्रह कर रहे हैं), जबकि भूमिकाओं अधिक हैं, क्योंकि अनुमतियों बहुत बारीक हैं लागू करने के लिए नहीं होगा अखंड। समूह/उपयोगकर्ता स्तर पर अनुमति विरासत/ओवरराइडिंग लागू करना बहुत मुश्किल नहीं होगा। भूमिकाओं के साथ ऐसा करना शायद अधिक कठिन होगा, लेकिन दूसरी ओर, औसत उपयोगकर्ता के लिए भूमिकाएं आसानी से समझी जा सकती हैं।

अभी, मैं अपने आप को "अनुमति केवल" मॉडल क्योंकि के प्रति अधिक झुकाव रहा हूँ:

• एप्लिकेशन शायद 30 से अधिक विभिन्न अनुमतियों की ज़रूरत नहीं होगी; , अगर मैं

लागू करने के लिए हालांकि एक से अधिक उपयोगकर्ता

अवधारणा स्पष्ट लगता है और इस तरह आसान की अनुमति प्रबंधन में आसानी -

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

Answer 1

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

ध्यान दें कि आरबीएसी में 'भूमिका' शब्द कुछ ऐसा है जो कार्यान्वयन को सीमित कर सकता है।

allow (a) role (to do an) action (on an) object 

स्यूडोकोड में आप इस तरह की एक विधि हो सकता है::

myRbac.allow(Member, View, Post) 

वहाँ तथापि है, कुछ भी नहीं है कि आप को रोकता है क्या मुझे लगता है कि मतलब है कि एक पारंपरिक RBAC प्रणाली इस तरह ठेठ नियम हैं है अमूर्त भूमिकाओं से। एक भूमिका आमतौर पर एक स्ट्रिंग नाम है। उस स्ट्रिंग नाम के साथ आप अपने समूह और उपयोगकर्ताओं को भी नाम दे सकते हैं। यदि आप इसे रचनात्मक रूप से उपयोग करते हैं तो 'रोल' आधारित भूमिकाओं से अधिक के लिए अनुमति देता है। इसे ऑब्जेक्ट आधारित या कुछ और कहें लेकिन अनिवार्य रूप से यह वही है: आप किसी चीज़ पर कुछ करने की अनुमति देते हैं।

allow (an) object (to do an) action (on an) object 

आप इस दृष्टिकोण से यह को देखें, तो अपने कार्यान्वयन, IMHO, काफी सरल कार्यान्वयन की लागत का औचित्य साबित करने की जाएगी। 'भूमिका' शब्द को कार्यान्वयन की सादगी को सीमित करने की अनुमति न दें। और यदि आप इसे सरल बना सकते हैं, तो इसके लिए क्यों न जाएं?

ऐसा लगता है जैसे आप PHP जानते हैं। यदि आप ज़ेंड फ्रेमवर्क एसीएल पर एक नज़र डालेंगे तो आपको एक कार्यान्वयन दिखाई देगा जो भूमिका आधारित है। शायद वह आपको प्रेरित करेगा।

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

पुन: आपका उदाहरण पदानुक्रम। Zend Framework ACL में यह इस तरह हो सकता है:

$acl->addRole(new Zend_Acl_Role('Role1')) 
    ->addRole(new Zend_Acl_Role('Group1', array('Role1')) 
    ->addRole(new Zend_Acl_Role('Group2', array('Group1)); 
$acl->allow('Role1', 'someAction', 'someObject'); // permission 1 
$acl->allow('Role1', 'otherAction', 'otherObject'); // permission 2 
$acl->deny('Group2', 'someAction', 'someObject'); 

ईमानदार यह कुछ समय मैं वास्तव में Zend_Acl में यह कर दिया है के बाद से मैं अपने खुद के सिस्टम बना रहा हूं हो गया है होना करने के लिए।

Answer 2

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

हम चाहते हैं कि संसाधन के प्रकार के अनुसार विवश कर रहे हैं polyarchical व्यापार भूमिकाओं और तकनीकी भूमिकाओं के साथ हमारे उत्पाद में एक बहुत जटिल RBAC लागू वे रक्षा - http://blog.identitymanagement.com/downloads/ माइक्रोसॉफ्ट के विंडोज पहचान फाउंडेशन नामक एक नया नया दावा आधारित प्रोग्रामिंग ढांचे है - सबसे संभालती है आपके लिए नलसाजी

पैट्रिक पार्कर