अभिगम नियंत्रण प्रेरित डिजाइन

Question

मैं DDD और अभिगम नियंत्रण के बारे में पढ़ा है, और मैं निम्नलिखित दो राय के बीच कुछ विरोधाभास पाया:

• "अभिगम नियंत्रण" सुरक्षा चिंताओं डोमेन के बाहर संभाला जाना चाहिए " आवश्यकताओं डोमेन विशिष्ट "

मैं इस बारे में सबसे अच्छा अभ्यास रहा हूँ कर रहे हैं। तो मुझे डोमेन संचालित डिज़ाइन द्वारा एक्सेस कंट्रोल लॉजिक कहां रखा जाना चाहिए, और मुझे इसे कैसे कार्यान्वित करना चाहिए?

(DDD + CQRS + ES करके अधिक विशिष्ट होना करने के लिए।)

मुझे लगता है कि कहीं न कहीं व्यापार तर्क के पास होना चाहिए, उदाहरण के लिए एक उपयोगकर्ता कहानी कुछ इस तरह हो सकता है:

उपयोगकर्ता एक उपयोगकर्ता नाम, शौक, सीवी, आदि की एक सूची भेज कर अपने प्रोफ़ाइल संपादित कर सकते हैं ...

उपयोगकर्ता कहानी हम डोमेन मॉडल और सेवाओं, उदाहरण के लिए लागू के आधार पर:

UserService 
    editProfile(EditUserProfileCommand command) 
     User user = userRepository.getOneById(command.id) 
     user.changeName(command.name) 
     user.changeHobbies(command.hobbies) 
     user.changeCV(command.cv) 

UserRepository 
    User getOneById(id) 

User 
    changeName(String name) 
    changeHobbies(String[] hobbies) 
    changeCV(String cv) 

यह ठीक है, लेकिन कहां है HIS profile कहानी का हिस्सा?

यह वह जगह है जाहिर है, आधारित अभिगम नियंत्रण विशेषता है क्योंकि हम इस तरह एक नियम के कुछ लिखना चाहिए:

deny all, but if subject.id = resource.owner.id then grant access 

लेकिन जहाँ हम इस नियम को लागू करना चाहिए, और हम इसे कैसे लागू करना चाहिए?

Answer 1

तो मुझे एक्सेस कंट्रोल लॉजिक कहां रखना चाहिए?

इस के अनुसार: https://softwareengineering.stackexchange.com/a/71883/65755 नीति प्रवर्तन बिंदु UserService.editProfile() की कॉल करने से पहले अधिकार होना चाहिए।

मैं एक ही निष्कर्ष पर आया: यह यूआई में नहीं हो सकता है क्योंकि एकाधिक यूआई द्वारा हमारे पास कोड पुनरावृत्ति होगी। यह डोमेन घटनाओं के निर्माण से पहले होना चाहिए, क्योंकि उन्होंने संकेत दिया है कि हमने पहले ही सिस्टम में कुछ किया है। इसलिए हम डोमेन ऑब्जेक्ट्स या उन डोमेन सेवाओं तक पहुंच प्रतिबंधित कर सकते हैं जो उन डोमेन ऑब्जेक्ट्स का उपयोग करते हैं। सीक्यूआरएस द्वारा हमारे पास पढ़ने के मॉडल, केवल सेवाओं द्वारा डोमेन ऑब्जेक्ट्स की आवश्यकता नहीं है, इसलिए यदि हमें सामान्य समाधान चाहिए तो हमें सेवाओं तक पहुंच प्रतिबंधित करनी होगी। हम प्रत्येक सेवा संचालन की शुरुआत में पहुंच निर्णय ले सकते थे, लेकिन यह grant all, deny x सुरक्षा विरोधी पैटर्न होगा।

मुझे इसे कैसे कार्यान्वित करना चाहिए?

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

मैंने एक्सेस कंट्रोल मॉडल की एक छोटी सूची बनाई है। मैं एनोटेशन में नियमों, नीतियों में कहें, लेकिन आम तौर पर हम उन्हें शायद XACML प्रारूप में एक डेटाबेस में स्टोर करता है, तो हम एक अच्छी तरह से पोषणीय प्रणाली करना चाहते हैं चाहिए ...

• पहचान आधारित अभिगम नियंत्रण द्वारा (IBAC) हम एक पहचान - अनुमति भंडारण (अभिगम नियंत्रण सूची, क्षमता सूची, अभिगम नियंत्रण मैट्रिक्स) है। तो उदाहरण के लिए एक एक्सेस कंट्रोल सूची द्वारा, हम उन उपयोगकर्ताओं या समूहों की सूची संग्रहीत करते हैं जिनके पास अनुमति हो सकती है।

  UserService 
      @AccessControlList[inf3rno] 
      editProfile(EditUserProfileCommand command) 
  

• जाली आधारित अभिगम नियंत्रण (LBAC) विषय एक निकासी स्तर है करने से संसाधन एक आवश्यक मंजूरी के स्तर का है, और हम जाँच जो स्तर अधिक है ...

  @posseses[level=5] 
  inf3rno 
  
  UserService 
      @requires(level>=3) 
      editProfile(EditUserProfileCommand command) 
  

• तक भूमिका आधारित अभिगम नियंत्रण (आरबीएसी) हम विषय भूमिकाओं को परिभाषित करते हैं और हम उन विषयों को अनुमति देते हैं जिनके कार्य वास्तविक भूमिका निभाते हैं।

  @roles[admin] 
  inf3rno 
  
  UserService 
      @requires(role=admin) 
      editProfile(EditUserProfileCommand command) 
  

• विशेषता आधारित अभिगम नियंत्रण (ABAC) हम विषय, संसाधन और पर्यावरण विशेषताएं निर्धारित है और हम उन पर आधारित हमारी नीतियों लिखने तक।

  @attributes[roles=[admin]] 
  inf3rno 
  
  UserService 
      @policy(subject.role=admin or resource.owner.id = subject.id) 
      editProfile(EditUserProfileCommand command) 
      @attribute(owner) 
      Subject getOwner(EditUserProfileCommand command) 
  

• नीति आधारित अभिगम नियंत्रण द्वारा (PBAC) हम अपनी नीतियों और कुछ करने के लिए निर्दिष्ट नहीं करते, वे स्टैंडअलोन कर रहे हैं।

  @attributes[roles=[admin]] 
  inf3rno 
  
  UserService 
      editProfile(EditUserProfileCommand command) 
      deleteProfile(DeleteUserProfileCommand command) 
      @attribute(owner) 
      Subject getOwner(EditUserProfileCommand command) 
  
  @permission(UserService.editProfile, UserService.deleteProfile) 
  @criteria(subject.role=admin or resource.owner.id = subject.id) 
  WriteUserServicePolicy 
  

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

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

  @attributes[roles=[editor]] 
  token:2683fraicfv8a2zuisbkcaac 
  
  ArticleService 
      @policy(subject.role=editor) 
      editArticle(EditArticleCommand command) 
  

  तो जो 2683fraicfv8a2zuisbkcaac टोकन सेवा का उपयोग कर सकते जानता है हर कोई: ABAC साथ उदाहरण के लिए।

और इतने पर ...

कई अन्य मॉडल हैं, और सबसे अच्छा फिट हमेशा अपने ग्राहक की जरूरतों पर निर्भर करता है।

तो संक्षेप में प्रस्तुत करने

- "security concerns should be handled outside the domain" 
- "access control requirements are domain specific" 

दोनों सही हो सकता है, क्योंकि सुरक्षा डोमेन मॉडल का हिस्सा नहीं है, लेकिन इसके कार्यान्वयन डोमेन मॉडल और एप्लिकेशन तर्क पर निर्भर करता है। 2 साल 2016-09-05

जब से मैं एक DDD नौसिखिया के रूप में अपने ही सवाल का जवाब के बाद

संपादित करें, मैं वॉन वेरनॉन से Implementing Domain-Driven Design पढ़ा है।यह विषय में एक दिलचस्प किताब थी। यहाँ यह एक उद्धरण है: - पहचान और एक्सेस प्रसंग -

यह एक नया घिरा प्रसंग का गठन किया और मानक DDD एकीकरण तकनीकों के माध्यम से अन्य घिरा संदर्भ द्वारा उपयोग किया जाएगा। उपभोग करने वाले संदर्भों के लिए पहचान और एक्सेस संदर्भ एक सामान्य सबडोमेन है। उत्पाद का नाम IdOvation नाम दिया जाएगा।

तो वेरनॉन के अनुसार संभवतः एक सामान्य सबडोमेन तक पहुंच नियंत्रण को स्थानांतरित करने का सबसे अच्छा समाधान है।