2008-10-10 12 views
39

वेब एप्लिकेशन के लिए भूमिका-आधारित पहुंच नियंत्रण ट्रैक करने के लिए सबसे अच्छी डेटाबेस स्कीमा क्या है?सर्वश्रेष्ठ रोल-आधारित एक्सेस कंट्रोल (आरबीएसी) डेटाबेस मॉडल

मैं रेल का उपयोग कर रहा हूं, लेकिन Google द्वारा लिंक किया गया आरबीएसी प्लगइन अनजान दिखता है (केवल 300 ही एसवीएन के लिए प्रतिबद्ध है; नवीनतम लगभग एक साल पहले था)।

अवधारणा स्क्रैच से लागू करने के लिए काफी सरल है, फिर भी जटिल और महत्वपूर्ण है कि यह सही हो रहा है।

तो दूसरों को उनके आरबीएसी मॉडल को कैसे आर्किटेक्ट और कार्यान्वित किया जाता है?

+0

एक ढांचा का उपयोग करें जो आपके लिए प्राधिकरण लागू करता है। CanCanCan या अन्य विशेषता आधारित एक्सेस कंट्रोल (एबीएसी) मॉडल में देखें उदा। एक्सएसीएमएल –

उत्तर

51

उस क्षेत्र में मेरी नहीं बल्कि बुनियादी ज्ञान के लिए, जिसे RBAC के बुनियादी अभिनेता हैं:

  • संसाधन।
  • अनुमतियां।
  • उपयोगकर्ता।
  • भूमिकाएं (यानी समूह)।

संसाधन < - की आवश्यकता होती है -> (एक या कई) अनुमतियां

भूमिकाओं < -> (एक या कई) अनुमतियां - का संग्रह कर रहे हैं।

उपयोगकर्ता < - हो सकता है -> (एक या कई) भूमिकाओं

इस तरह के एक मॉडल के लिए टेबल होगा:

  • अनुमति
  • भूमिका
  • उपयोगकर्ता
  • role_permission
  • USER_ROLE

अब आप यहां संसाधनों शामिल करने के लिए चाहते हो सकता है साथ ही यदि आप अपने आवेदन के उपयोगकर्ताओं को चाहते हैं एक संसाधन की आवश्यकता के लिए कौन सी अनुमतियों को कॉन्फ़िगर करने में सक्षम है। लेकिन मुझे इसकी कभी आवश्यकता नहीं थी। उम्मीद है की वो मदद करदे।

+1

जब आप कहते हैं कि 'संसाधनों की आवश्यकता होती है (एक या कई) अनुमतियां', मुझे लगता है कि यह उस संसाधन के यूआई के लिए है, जो उपयोगकर्ता को प्रत्येक उपयोगकर्ता के लिए प्रत्येक अनुमति के मानों को अनुमति/अस्वीकार करने की अनुमति देता है ... सही ? यदि ऐसा है, तो अपने डीबी स्कीमा में, आपके पास एक अनुमति के साथ जुड़े 10, 20 (या अधिक) संभावित संसाधन हो सकते हैं। उदाहरण के लिए, 'प्रोजेक्ट मैनेजर' की 'बनाएं' अनुमति होती है। फिर आप इस तरह की अनुमति को परियोजना, अनुसूची, कार्य, दस्तावेज़, टाइम्सशीट संसाधन (केवल कुछ नाम देने के लिए) से जोड़ देंगे, क्योंकि एक प्रोजेक्ट मैनेजर उन सभी संसाधनों को बना सकता है? धन्यवाद! – Jeach

+0

मैं इसे अवधारणा में समझता हूं लेकिन मूलभूत मूल्यों के लिए तालिका संरचना कैसा दिख सकता है? – HPWD

+0

मैं समान अनुमतियों को कैसे समूहबद्ध करूं ताकि यह मुझे फ्रंटेंड में प्रदर्शित करने में सहायता करे? –

2

आप Restful ACL Rails plugin का उपयोग कर सकते हैं।

+0

यही वह है जो मैं करता हूं। – allesklar

+5

RESTful_ACL अच्छा है, लेकिन इसमें भूमिका-आधारित नियंत्रण की कोई अंतर्निहित अवधारणा नहीं है, इसलिए यह वास्तव में एक आरबीएसी समाधान नहीं है। –

+0

ठीक है, आरबीएसी! = मेरी राय में एसीएल। – mlinuxgada

0

.NET अनुप्रयोगों के लिए आपको स्क्रैच से अनुमतियों और भूमिकाओं को संभालने से बचने के लिए विजुअल गार्ड http://www.visual-guard.com/ जैसे कुछ देखना चाहिए।

इसके अलावा .net के लिए, आपके पास सदस्यता और भूमिका प्रदाता और प्रमाणीकरण के साथ प्राधिकरण प्राधिकरण है। http://www.odetocode.com/Articles/427.aspx

0

Role Requirement भूमिका-आधारित लेख कार्यों को प्रदान करने के लिए बहुत अच्छी तरह से विश्वसनीय प्रमाणीकरण के साथ काम करता है और अच्छी तरह से बनाए रखा जाता है।

+0

वेब पेज का कहना है कि इसे अब बनाए रखा नहीं गया है :-( –

+0

हाँ, कुछ सालों में क्या अंतर होता है। :) व्यक्तिगत रूप से, मैंने प्रमाणीकरण के लिए डेविस का उपयोग करने और रोल-अप-रोल रोल असाइनमेंट और कैनकन के संयोजन के लिए उपयोग किया है मेरी अधिकांश प्रमाणीकरण की जरूरत है। रेलसकास्ट # 1 9 2 (http://railscasts.com/episodes/192- प्राधिकरण-with-cancan) देखने के बाद मैंने इस सड़क को शुरू कर दिया। मैं उपयोगकर्ता भूमिकाओं को संग्रहीत करने के बाइनरी-मास्किंग विधि का प्रशंसक हूं। – Yardboy

3

मैं यहां पर काम पर आरबीएसी उप-प्रणाली पर काम कर रहा हूं ... क्या एक संयोग है।

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

rule 14: guest role + page name + read permission 
rule 46: approver role + add column + execute permission 

और इसी तरह। मैं ईआरडी को पाठक को अभ्यास के रूप में छोड़ दूंगा ;-) यदि आपके कोई प्रश्न हैं, तो एक टिप्पणी छोड़ दें।

युवाल = 8-)

+0

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

+0

यह वास्तव में एक उपरि है, और डेवलपर को संसाधन लिखने, या इस क्रॉस-एप्लिकेशन सुविधा के लिए जिम्मेदार व्यक्ति द्वारा देखभाल की जानी चाहिए। यह सिंक्रनाइज़ेशन कोड की तरह है ... या तो यह हर जगह दिखाई देता है, या यह अच्छा नहीं है। – Yuval

0

मैं वास्तव में इस ब्लॉग पोस्ट, http://pivotallabs.com/users/nick/blog/articles/272-access-control-permissions-in-rails की तरह।

संपादित करें:

यह उसी तर्ज पर सोचा Railscasts की कि ryanb लगता है और एक मणि कैनकैन https://github.com/ryanb/cancan नामक pivotollabs पोस्ट करने के लिए इसी तरह की एक बुनियादी तकनीक का उपयोग कर।

1

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

मैं युवाल के उत्तर के करीब हूं, हमें केवल परियोजना-व्यापी वस्तुओं + क्रियाओं + उपयोगकर्ताओं को जोड़ना है। इसे प्रदान करने के लिए; एक मूल वस्तु (इकाई) सही समझ में आता है। एंटिटी से विरासत में प्राप्त किसी भी वस्तु को इस तरह से उपयोगकर्ता + एक्शन से आसानी से जोड़ा जा सकता है।

जैसा कि आप चीजों को सरल रखना चाहते हैं; मेरा सुझाव होगा;

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

बातें एक कदम आगे ले, मैं भी (एक स्वचालित RBAC के लिए) निम्नलिखित

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

लेकिन हां, यह सिर्फ .NET के लिए उपलब्ध है, जहां तक ​​मुझे पता है कि जावा में कस्टम विशेषताओं नहीं हैं, इसलिए जावा के लिए अभी तक उपलब्ध होने की संभावना नहीं है।

मैं कुछ कोड उदाहरणों के साथ आना चाहता हूं लेकिन मैं ऐसा करने के लिए बहुत आलसी हूं। फिर भी अगर आपके पास आरबीएसी के रास्ते के बारे में कोई सवाल है; आप यहां पूछ सकते हैं और मैं निश्चित रूप से जवाब दूंगा।

भूमिका आधारित अभिगम नियंत्रण प्रणाली 'के लिए कुछ सूत्रों या अनुप्रयोगों या की कुछ सुविधाओं एक्सेस को प्रतिबंधित करने का एक तरीका है -

19

यहाँ RBAC को Amr Mostafa's excellent answer

enter image description here

+5

आपको UserRoleID और RolePermissionID का उपयोग करने की आवश्यकता नहीं है। User_Role में इसके बजाय, उपयोगकर्ता आईडी और रोलआईडी का संयोजन अद्वितीय और प्राथमिक कुंजी होना चाहिए। रोलआईडमिशन तालिका के लिए यह रोलआईड और अनुमति आईडी के साथ समान है। – guuspor

-1

परिचय वर्णन करने के लिए एक सरल चित्र है आवेदन 'संगठन के उपयोगकर्ताओं की भूमिका के आधार पर।

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

और यदि हम आरबीएसी में थोड़ा गहराई से जाते हैं, तो मूल रूप से इसमें 3 विशेषताएं होती हैं।

1) प्रमाणीकरण - यह उपयोगकर्ता की पहचान की पुष्टि करता है। आमतौर पर यह उपयोगकर्ता खातों और पासवर्ड या प्रमाण पत्र के माध्यम से किया जाता है।

2) प्राधिकरण - यह परिभाषित करता है उपयोगकर्ता क्या कर सकते हैं और एक आवेदन में ऐसा नहीं कर सकते क्या। पूर्व। 'संशोधित आदेश' की अनुमति है लेकिन 'नया ऑर्डर बनाना' की अनुमति नहीं है।

3) अनुप्रयोगों पर उपयोगकर्ता कार्यों की लेखा परीक्षा। - यह अनुप्रयोगों पर उपयोगकर्ता के कार्यों का ट्रैक रखता है, साथ ही साथ किसने उपयोगकर्ताओं को किस तक पहुंच प्रदान की है?

यह RBAC प्रणाली के बहुत ही बुनियादी शीर्ष दृश्य तस्वीर थी।

आरबीएसी सिस्टम के मूल संरचना में निम्नलिखित घटक हो सकते हैं: उपयोगकर्ता, भूमिकाएं, अनुमतियां या प्रतिबंध, संसाधन।

  • अनुमतियां या प्रतिबंध - अनुमतियां एप्लिकेशन के संसाधन तक पहुंच का प्रतिनिधित्व करती हैं।
  • भूमिका - यह अनुमतियों के संग्रह होता
  • उपयोगकर्ता - उपयोगकर्ता को असाइन एकल या अधिक भूमिकाएं, इसलिए अंत उपयोगकर्ता भूमिका के साधनों के माध्यम से अनुमतियाँ शामिल हैं।

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

आप अधिक जानकारी के लिए इस लेख की जाँच कर सकते हैं:

0

https://github.com/ThoughtWorksStudios/piece का प्रयास करें, तो यह आपको उपयोगकर्ता भूमिका आधारित अभिगम नियंत्रण का प्रबंधन करने के लिए एक नियम इंजन है:

  1. परिभाषित अभिगम नियंत्रण नियमों
  2. कम्बाइन नए नियम बनाने के नियम

आप यहां पूर्ण रेल एप्लिकेशन उदाहरण पा सकते हैं: https://github.com/xli/piece-blog

संबंधित मुद्दे