ব্যবহারের প্রধান সুবিধা কি CBAC বনাম RBAC ? কখন সিবিএসি ব্যবহার করা ভাল এবং আরবিএসি ব্যবহার করা কখন ভাল?
আমি সিবিএসি মডেলের সাধারণ ধারণাগুলি বোঝার চেষ্টা করছি তবে সাধারণ ধারণাটি এখনও আমার পক্ষে পরিষ্কার নয়।
উত্তর:
আমি কোনও এএসপি.নেট এমভিসি কনটেক্সটে কীভাবে দাবি ভিত্তিক অ্যাক্সেস নিয়ন্ত্রণ থেকে উপকৃত হতে পারি তা দেখানোর চেষ্টা করব।
আপনি যখন রোল ভিত্তিক প্রমাণীকরণ ব্যবহার করছেন, আপনার যদি গ্রাহক তৈরি করার জন্য যদি কোনও পদক্ষেপ থাকে এবং আপনি চান যে 'বিক্রয়' রোলের লোকেরা তা করতে সক্ষম হন তবে আপনি এই জাতীয় কোডটি লিখুন:
[Authorize(Roles="Sale")]
public ActionResult CreateCustomer()
{
return View();
}
পরে আপনি বুঝতে পেরেছিলেন যে, কখনও কখনও 'বিপণন' ভূমিকার লোকদের গ্রাহক তৈরি করতে সক্ষম হওয়া উচিত। তারপরে, আপনি আপনার অ্যাকশন পদ্ধতিটি আপডেট করুন
[Authorize(Roles = "Sale", "Marketing")]
public ActionResult CreateCustomer()
{
return View();
}
এখন, আপনি বুঝতে পেরেছেন যে, বিপণনের কিছু লোক অবশ্যই গ্রাহক তৈরি করতে সক্ষম হবে না, তবে যারা বিপণনে আছেন তাদের জন্য আলাদা ভূমিকা নির্ধারণ করা সম্ভব নয়। সুতরাং, আপনি সমস্ত বিপণনের লোককে গ্রাহক তৈরি করার অনুমতি দিতে বাধ্য হচ্ছেন।
আপনি অন্য একটি সমস্যা চিহ্নিত করেছেন, যে কোনও সময় আপনি সিদ্ধান্ত নেন যে বিপণন লোকদের গ্রাহক তৈরি করার অনুমতি দেওয়া উচিত, আপনাকে আপনার সমস্ত এমভিসি অ্যাকশন পদ্ধতিগুলি বৈশিষ্ট্য অনুমোদন করতে হবে, আপনার অ্যাপ্লিকেশনটি সংকলন করতে হবে, পরীক্ষা করতে হবে এবং মোতায়েন করতে হবে। কিছু দিন পরে, আপনি সিদ্ধান্ত নিয়েছিলেন, বিপণন নয় তবে অন্য কিছু ভূমিকার পক্ষে কাজটি করার অনুমতি দেওয়া উচিত, সুতরাং আপনি আপনার কোডবেসে অনুসন্ধান করুন এবং অনুমোদনযোগ্য বৈশিষ্ট্য থেকে সমস্ত 'বিপণন' মুছুন এবং অনুমোদনের বৈশিষ্ট্যে আপনার নতুন ভূমিকার নাম যুক্ত করুন ... একটি নয় স্বাস্থ্যকর সমাধান। এই মুহুর্তে, আপনি অনুমতি ভিত্তিক অ্যাক্সেস নিয়ন্ত্রণের প্রয়োজনীয়তা বুঝতে পারবেন।
অনুমতি ভিত্তিক অ্যাক্সেস নিয়ন্ত্রণ বিভিন্ন ব্যবহারকারীর জন্য বিভিন্ন অনুমতি বরাদ্দ করার এবং চালকের সময়টিতে কোনও ব্যবহারকারীর কোড থেকে কোনও ক্রিয়াকলাপ চালানোর অনুমতি আছে কিনা তা যাচাই করার একটি উপায়। আপনি বিভিন্ন ব্যবহারকারীর কাছে বিভিন্ন অনুমতি বরাদ্দের পরে, আপনি বুঝতে পেরেছেন যে "ফেসবুক ব্যবহারকারী", "দীর্ঘকালীন ব্যবহারকারী" ইত্যাদির মতো ব্যবহারকারীর কিছু সম্পত্তি থাকলে কিছু ব্যবহারকারীকে কিছু কোড কার্যকর করতে অনুমতি দেওয়া দরকার আমাকে একটি উদাহরণ দিন give বলুন যে ব্যবহারকারী যদি ফেসবুক ব্যবহার করে লগ ইন করেন তবে আপনি একটি নির্দিষ্ট পৃষ্ঠায় অ্যাক্সেসের অনুমতি দিতে চান। এখন, আপনি কি সেই ব্যবহারকারীর জন্য একটি অনুমতি 'ফেসবুক' তৈরি করবেন? না, 'ফেসবুক' কোনও অনুমতি মতো শোনাচ্ছে না। এটা কি পারে ? বরং এটি দাবির মতো শোনাচ্ছে। একই সাথে, অনুমতিগুলিও দাবির মতো শোনাতে পারে !! সুতরাং, দাবিগুলির জন্য পরীক্ষা করা এবং অ্যাক্সেসের অনুমতি দেওয়া ভাল।
এখন, দাবি ভিত্তিক অ্যাক্সেস নিয়ন্ত্রণের সুনির্দিষ্ট উদাহরণে ফিরে যাই।
আপনি এই জাতীয় কিছু দাবির সংজ্ঞা দিতে পারেন:
"CanCreateCustomer", "CanDeleteCustomer", "CanEditCustomer" .. ইত্যাদি ..
এখন, আপনি নিজের ক্রিয়া পদ্ধতিটি এভাবে সাজিয়ে তুলতে পারেন:
[ClaimAuthorize(Permission="CanCreateCustomer")]
public ActionResult CreateCustomer()
{
return View();
}
(দয়া করে নোট করুন, [দাবি দাবি করুন (অনুমতি = "ক্যানক্রিয়েট কাস্টমার"))] এমভিসি ক্লাস লাইব্রেরিতে তৈরি নাও হতে পারে, আমি কেবল উদাহরণ হিসাবে দেখিয়ে দিচ্ছি, আপনি এমন কিছু শ্রেণিকালীন গ্রন্থাগার ব্যবহার করতে পারেন যার এমন বৈশিষ্ট্য শ্রেণীর সংজ্ঞা রয়েছে)
এখন, আপনি দেখতে পাচ্ছেন যে ক্রিয়েটস কাস্টমোর অ্যাকশন পদ্ধতির জন্য সর্বদা 'ক্যানক্রিয়েট কাস্টমার' এর অনুমতি প্রয়োজন হবে এবং এটি কখনই পরিবর্তন বা শক্তভাবে পরিবর্তন হবে না। সুতরাং, আপনার ডাটাবেজে, আপনি অনুমতিগুলির একটি টেবিল তৈরি করেন (দাবি) এবং ব্যবহারকারীর অনুমতি সম্পর্কিত। আপনার প্রশাসক প্যানেল থেকে, আপনি প্রতিটি ব্যবহারকারীর জন্য অনুমতি (দাবি) সেট করতে পারেন যারা কি করতে পারে। আপনি নিজের পছন্দ মতো যাকে 'CanCreateCustomer' অনুমতি (দাবি) অর্পণ করতে পারেন এবং কেবল অনুমোদিত ব্যবহারকারী গ্রাহক তৈরি করতে সক্ষম হবেন এবং অনুমোদিত ব্যবহারকারী কেবলমাত্র গ্রাহক তৈরি করতে সক্ষম হবেন এবং অন্য কোনও কিছুই তৈরি করতে পারবেন না (যদি আপনি একই ব্যবহারকারীর সাথে অন্য অনুমতিগুলি বরাদ্দ না করেন)।
এই সুরক্ষা মডেল আপনাকে ক্লিন কোড অনুশীলনের প্রস্তাব দেয়। তদ্ব্যতীত, আপনি যখন আপনার অ্যাকশন পদ্ধতিটি লেখেন তখন আপনাকে এই পদ্ধতিটি কে ব্যবহার করতে পারে তা নিয়ে ভাবতে হবে না, বরং আপনাকে সর্বদা নিশ্চিত করা যেতে পারে যে এই পদ্ধতিটি যে ব্যবহার করছে তাকে প্রশাসকের দেওয়া যথাযথ অনুমতি (দাবি) থাকবে। তারপরে, অ্যাডমিন সিদ্ধান্ত নিতে পারে কে কারা সক্ষম হতে পারবে। আপনি বিকাশকারী হিসাবে নয়। আপনার ব্যবসায়ের যুক্তি কীভাবে সুরক্ষা যুক্তি থেকে পৃথক করা হয়েছে তা স্থির করে।
যখনই কেউ সাইন ইন করে, আপনার অ্যাপ্লিকেশনটি সেই ব্যবহারকারীর জন্য যা কিছু অনুমতি রয়েছে তা যাচাই করবে এবং সেই অনুমতি (দাবি) সেটটি বর্তমানে লগ ইন করা ব্যবহারকারীর অতিরিক্ত বৈশিষ্ট্য হিসাবে উপলব্ধ হবে (সাধারণত দাবি সেটটি লগ-ইন করা ব্যবহারকারীর জন্য কুকি হিসাবে সংরক্ষণ করা হয়), সুতরাং আপনাকে ডাটাবেস থেকে সমস্ত সময় অনুমতি সেট পরীক্ষা করতে হবে না। নীচের লাইনটি হল, আপনি যদি ভূমিকা ভিত্তিক অ্যাক্সেসের পরিবর্তে দাবি ভিত্তিক অ্যাক্সেস প্রয়োগ করেন তবে আপনি আপনার অ্যাপ্লিকেশনটিতে আপনার সুরক্ষা যুক্তির আরও নিয়ন্ত্রণ পেতে পারেন। আসলে, কোনও ভূমিকাকেও দাবি হিসাবে বিবেচনা করা যেতে পারে।
যদি আপনার অ্যাপ্লিকেশনটি খুব সামান্য অ্যাপ্লিকেশন হয় যেখানে কেবলমাত্র 2 টি ভূমিকা থাকবে: গ্রাহক এবং প্রশাসক এবং গ্রাহকরা আপনার আবেদনে যা করতে চান তা ব্যতীত অন্য কিছু করতে সক্ষম হবেন এমন সম্ভাবনা নেই, তবে সম্ভবত ভূমিকা ভিত্তিক অ্যাক্সেস নিয়ন্ত্রণ উদ্দেশ্যটি পরিবেশন করবে, তবে আপনার অ্যাপ্লিকেশনটি বাড়ার সাথে সাথে আপনি কোনও পর্যায়ে দাবি ভিত্তিক অ্যাক্সেস নিয়ন্ত্রণের প্রয়োজনীয়তা অনুভব করতে শুরু করবেন।
CanCreateCustomer, CanViewAdCampaigns
আমি এখন অনেকবার সুরক্ষা মডেলগুলি প্রয়োগ করেছি এবং এই ধারণাগুলির পাশাপাশি আমার মাথাও জড়িয়ে রাখতে হয়েছিল। এটি বহুবার সম্পন্ন করার পরে, এই ধারণাগুলি সম্পর্কে আমার উপলব্ধি।
ভূমিকা কি
ভূমিকা = ব্যবহারকারী এবং অনুমতিগুলির ইউনিয়ন ।
একদিকে, একটি ভূমিকা হল অনুমতিগুলির সংগ্রহ collection আমি এটিকে অনুমতি প্রোফাইল বলতে চাই। কোনও ভূমিকা সংজ্ঞায়িত করার সময় আপনি মূলত সেই ভূমিকাটিতে একগুচ্ছ অনুমতিগুলি যুক্ত করেন যাতে সেই অর্থে কোনও ভূমিকা একটি অনুমতি প্রোফাইল।
অন্যদিকে, একটি ভূমিকাও ব্যবহারকারীদের সংগ্রহ। যদি আমি বব এবং অ্যালিসকে ভূমিকা "পরিচালকদের" সাথে যুক্ত করি তবে "ম্যানেজারস" এ এখন একটি গ্রুপের মতো দুটি ব্যবহারকারীর সংকলন রয়েছে।
সত্যটি হ'ল একটি ভূমিকা হ'ল ব্যবহারকারীদের সংগ্রহ এবং অনুমতিগুলির সংকলন একসাথে রাখা। দৃশ্যত এটি ভেন চিত্র হিসাবে দেখা যেতে পারে।
একটি গ্রুপ কি
গ্রুপ = ব্যবহারকারীর সংগ্রহ Collection
একটি "গ্রুপ" কঠোরভাবে ব্যবহারকারীদের সংগ্রহ a একটি গোষ্ঠী এবং একটি ভূমিকার মধ্যে পার্থক্য হ'ল কোনও ভূমিকাতেও অনুমতিগুলির সংকলন থাকে তবে একটি গোষ্ঠীতে কেবল ব্যবহারকারীদের সংগ্রহ থাকে।
পারমিশন কী?
অনুমতি = কোন বিষয় কী করতে পারে
একটি অনুমতি সেট কি
অনুমতি সেট = অনুমতি সংগ্রহ
একটি শক্তসমর্থ আরবিএসি সিস্টেমে অনুমতিগুলিও ব্যবহারকারীদের মতো গোষ্ঠীযুক্ত করা যেতে পারে। যদিও গোষ্ঠীগুলি কেবলমাত্র ব্যবহারকারীদের সংগ্রহ, তবে অনুমতি সেট কেবল অনুমতিগুলির সংগ্রহ। এটি প্রশাসককে একবারে ভূমিকাগুলির পুরো সংগ্রহগুলি যোগ করতে দেয়।
কীভাবে ব্যবহারকারী, গোষ্ঠী, ভূমিকা এবং অনুমতি একসাথে আসে
একটি শক্তিশালী আরবিএসি সিস্টেমে, ব্যবহারকারীদের ভূমিকা বা গোষ্ঠীগুলির মধ্যে ব্যবহারকারী সংগ্রহ সংগ্রহ করতে স্বতন্ত্রভাবে একটি ভূমিকার সাথে যুক্ত করা যেতে পারে একসময় ভূমিকাটিতে ব্যবহারকারীদের সংকলন যুক্ত করতে একটি ভূমিকাতে যুক্ত করা যেতে পারে। যে কোনও উপায়ে, ভূমিকাটি ব্যবহারকারীদের নিজস্ব স্বতন্ত্রভাবে যোগ করা থেকে বা ভূমিকার সাথে গ্রুপগুলি যুক্ত করার মাধ্যমে বা ভূমিকাটিতে ব্যবহারকারী এবং গোষ্ঠীগুলির মিশ্রণ যোগ করে সংগ্রহ করে। অনুমতিগুলি একইভাবে চিন্তা করা যেতে পারে।
ভূমিকার ভিতরে অনুমতিগুলির সংগ্রহ তৈরি করার জন্য অনুমতিগুলিতে পৃথক পৃথকভাবে ভূমিকাগুলিতে যুক্ত করা যেতে পারে বা অনুমতি সেটগুলির কোনও ভূমিকাতে যুক্ত করা যেতে পারে। অবশেষে, অনুমতি এবং অনুমতি সেটগুলির একটি মিশ্রণ একটি ভূমিকার সাথে যুক্ত হতে পারে। যেভাবেই হোক, ভূমিকাটি পৃথকভাবে যুক্ত হওয়া বা কোনও ভূমিকাতে অনুমতি সেট যুক্ত করে এর অনুমতি সংগ্রহের সঞ্চার করে।
রোলসের পুরো উদ্দেশ্য হ'ল ব্যবহারকারীদের অনুমতিগুলিতে বিবাহ করা। সুতরাং, একটি ভূমিকা ব্যবহারকারী এবং অনুমতিগুলির ইউনিয়ন।
কী দাবি?
দাবি = কী বিষয় "তা"
দাবিগুলি অনুমতি নেই। পূর্বের উত্তরে যেমন উল্লেখ করা হয়েছে, দাবি দাবি হ'ল একটি বিষয় যা "বিষয়" কী করতে পারে তা "বিষয়" কী করতে পারে না "।
দাবিগুলি ভূমিকা বা অনুমতিগুলি প্রতিস্থাপন করে না, তারা অতিরিক্ত তথ্যের টুকরো যা কোনও অনুমোদনের সিদ্ধান্ত নিতে ব্যবহার করতে পারে।
দাবি কখন ব্যবহার করবেন Use
আমি যখন দাবিতে কার্যকর হতে পারি তখন যখন কোনও ভূমিকায় ব্যবহারকারীকে যুক্ত করা যায় না বা সিদ্ধান্ত ব্যবহারকারীকে অনুমতি দেওয়ার ভিত্তিতে না হয় তখন অনুমোদনের সিদ্ধান্ত নেওয়া দরকার বলে আমি খুঁজে পেয়েছি। ফেসবুক ব্যবহারকারীর উদাহরণ এর কারণ। ফেসবুক ব্যবহারকারী এমন কেউ নাও হতে পারেন যাকে "ভূমিকা" এ যুক্ত করা হয় ... তারা ফেসবুকের মাধ্যমে অনুমোদিত কিছু দর্শক itor যদিও এটি আরবিএসি তে খুব সুন্দরভাবে ফিট করে না তবে অনুমোদনের সিদ্ধান্ত নেওয়ার জন্য এটি তথ্যের একটি অংশ।
@ কোডিংসফট পূর্বের উত্তরে নাইট ক্লাব রূপক ব্যবহার করেছে, যা আমি প্রসারিত করতে চাই। এই উত্তরে, ড্রাইভারের লাইসেন্সটি উদাহরণ হিসাবে ব্যবহৃত হয়েছিল যাতে দাবির একটি সেট থাকে যেখানে জন্ম তারিখ দাবিগুলির মধ্যে একটির প্রতিনিধিত্ব করে এবং ডেটঅফবার্থ দাবির মান অনুমোদনের নিয়মের বিরুদ্ধে পরীক্ষার জন্য ব্যবহৃত হয়। যে সরকার ড্রাইভারের লাইসেন্স জারি করেছে তা হ'ল কর্তৃপক্ষ যা দাবিটিকে সত্যতা দেয়। অতএব, একটি নাইট ক্লাবের দৃশ্যে, দরজার দিকে বাউন্সারটি সেই ব্যক্তির ড্রাইভার লাইসেন্স দেখে, নিশ্চিত করে যে এটি কোনও বিশ্বস্ত কর্তৃপক্ষ দ্বারা জাল আইডি কিনা (যেমন বৈধ সরকার জারি করা আইডি হতে হবে) তা পরীক্ষা করেই জারি করা হয়েছিল, তারপরে জন্ম তারিখটি দেখুন (ড্রাইভারের লাইসেন্সে থাকা বহু দাবির মধ্যে একটি), তারপরে সেই মানটি ব্যবহার করে ব্যক্তিটি ক্লাবে প্রবেশের জন্য যথেষ্ট বয়স্ক কিনা তা নির্ধারণ করতে। যদি তাই,
এখন, সেই বেসটি মাথায় রেখে আমি এখন আরও আরও বাড়িয়ে দিতে চাই। মনে করুন যে নাইট ক্লাবটি যে বিল্ডিংটিতে অফিস, ঘর, একটি রান্নাঘর, অন্যান্য তল, লিফট, একটি বেসমেন্ট ইত্যাদি রয়েছে যেখানে কেবল ক্লাবের কর্মীরা প্রবেশ করতে পারবেন। তদতিরিক্ত, নির্দিষ্ট কর্মীদের নির্দিষ্ট জায়গায় অ্যাক্সেস থাকতে পারে যা অন্য কর্মীরা নাও পারে। উদাহরণস্বরূপ, কোনও পরিচালকের উপরে অফিসের ফ্লোরে অ্যাক্সেস থাকতে পারে যা অন্য কর্মীরা অ্যাক্সেস করতে পারে না। এই ক্ষেত্রে দুটি ভূমিকা আছে। পরিচালক এবং কর্মচারী।
উপরে বর্ণিত হিসাবে পাবলিক নাইট ক্লাব অঞ্চলে দর্শকদের অ্যাক্সেস একক দাবির দ্বারা অনুমোদিত, কর্মচারীদের রোলের মাধ্যমে অন্যান্য অ-সরকারী বিধিনিষেধযুক্ত কক্ষে অ্যাক্সেস প্রয়োজন। তাদের জন্য, ড্রাইভারের লাইসেন্স যথেষ্ট নয়। তাদের যা দরকার তা হল একটি কর্মচারী ব্যাজ যা তারা দরজায় প্রবেশের জন্য স্ক্যান করে। কোথাও একটি আরবিএসি সিস্টেম রয়েছে যা উপরের তলায় ম্যানেজার রোলটিতে ব্যাজগুলি এবং কর্মচারী ভূমিকাতে ব্যাজগুলি অন্যান্য ঘরে অ্যাক্সেস দেয়।
যদি কোনও কারণে রোলের মাধ্যমে নির্দিষ্ট কক্ষগুলি যুক্ত / সরানোর প্রয়োজন হয় তবে এটি আরবিএসি ব্যবহার করে করা যেতে পারে, তবে এটি দাবির পক্ষে উপযুক্ত নয়।
সফ্টওয়্যার অনুমতি
অ্যাপ্লিকেশন মধ্যে ভূমিকা কোডিং একটি খারাপ ধারণা। এই হার্ড অ্যাপ্লিকেশন মধ্যে ভূমিকা উদ্দেশ্য কোড। অ্যাপ্লিকেশনটিতে যা হওয়া উচিত তা কেবল ফিচার ফ্ল্যাগের মতো কাজ করে এমন অনুমতি missions বৈশিষ্ট্যযুক্ত পতাকাগুলি কনফিগারেশনের মাধ্যমে অ্যাক্সেসযোগ্য করা হয়েছে, ব্যবহারকারীকে দেওয়া সমস্ত ভূমিকা থেকে সংগৃহীত অনুমতি সংগ্রহের DISTINCT সংগ্রহের মাধ্যমে প্রাপ্ত অনুমতিগুলি ব্যবহারকারীর সুরক্ষা প্রসঙ্গ দ্বারা অ্যাক্সেসযোগ্য করা হয়েছে This এটাকেই আমি "কার্যকর অনুমতি" বলি। অ্যাপ্লিকেশনটিতে কেবল একটি মেনু উপস্থাপন করা উচিতবৈশিষ্ট্য / ক্রিয়াকলাপের সম্ভাব্য অনুমতি। আরবিএসি সিস্টেমের উচিত সেই অনুমতিগুলি ব্যবহারকারীর সাথে রোলসের মাধ্যমে বিবাহ করার কাজ করা উচিত। এইভাবে, রোলগুলির কোনও হার্ড কোডিং নেই এবং কেবলমাত্র অনুমতিটি পরিবর্তন করা হয় যখন এটি সরানো হয় বা একটি নতুন যুক্ত করা হয়। সফ্টওয়্যারটিতে একবার অনুমতি যুক্ত হয়ে গেলে তা কখনই পরিবর্তন করা উচিত নয়। এটি শুধুমাত্র যখন প্রয়োজন তখন অপসারণ করা উচিত (অর্থাত্ যখন কোনও নতুন সংস্করণে কোনও বৈশিষ্ট্য বন্ধ করা হয়) এবং কেবলমাত্র একটি নতুন যুক্ত করা যায়।
একটি চূড়ান্ত নোট।
গ্রান্ট বনাম অস্বীকৃতি
একটি শক্তিশালী আরবিএসি সিস্টেম এমনকি একটি সিবিএসি সিস্টেমেরও অনুদান এবং অস্বীকারের মধ্যে পার্থক্য করা উচিত।
কোনও ভূমিকার সাথে অনুমতি যুক্ত করা কোনও অনুদান বা একটি ডেইনির সাথে আসা উচিত। যখন অনুমতিগুলি চেক করা হয়, তখন সমস্ত গ্রান্টেড অনুমতি কার্যকর ব্যবহারকারীদের তালিকার ব্যবহারকারীদের তালিকায় যুক্ত করা উচিত। তারপরে যা কিছু করা যায় তার পরে, DENIED অনুমতিগুলির একটি তালিকার ফলে সিস্টেমকে কার্যকর অনুমতিগুলির তালিকা থেকে সেই অনুমতিগুলি সরিয়ে ফেলা উচিত।
এটি প্রশাসকের কোনও বিষয়ের চূড়ান্ত অনুমতিগুলি "টুইঙ্ক" করতে দেয়। অনুমতিগুলিও সরাসরি ব্যবহারকারীদের সাথে যুক্ত করা যায় তবে সবচেয়ে ভাল। এইভাবে, আপনি কোনও ব্যবস্থাপকের ভূমিকাতে কোনও ব্যবহারকারীকে যুক্ত করতে পারেন এবং তারা সমস্ত কিছুতে অ্যাক্সেস পেতে পারেন তবে সম্ভবত আপনি লেডির রেস্টরুমে ডেইন অ্যাক্সেস করতে চান কারণ ব্যবহারকারী একজন পুরুষ। সুতরাং আপনি পুরুষ ব্যবহারকারীকে ম্যানেজারের ভূমিকায় যুক্ত করেন এবং DENY এর সাথে ব্যবহারকারী অবজেক্টে একটি অনুমতি যুক্ত করেন যাতে এটি কেবল লেডির ঘরে অ্যাক্সেস সরিয়ে নেয়।
আসলে, এটি একটি দাবির পক্ষে ভাল প্রার্থী হবে। যদি ব্যবহারকারীর একটি দাবি "লিঙ্গ = পুরুষ" থাকে তবে পরিচালকের ভূমিকাতে থাকা অবস্থায় সমস্ত কক্ষে অ্যাক্সেস দেওয়া হয় তবে লেডির রেস্টরুমেও দাবি জেন্ডার = মহিলা প্রয়োজন হয় এবং পুরুষদের রেস্টরুমে দাবি লিঙ্গ = পুরুষ প্রয়োজন। এই পদ্ধতিতে পুরুষ ব্যবহারকারীদের জন্য একটি DENY অনুমতি কনফিগার করতে হবে না যেহেতু দাবি প্রয়োগকারী একক অনুমোদনের নিয়মযুক্ত প্রত্যেকের জন্য এটি যত্ন নেয়। তবে এটি যেভাবেই করা যেত।
মুল বক্তব্যটি হ'ল অনুমোদনের DENIAL এর সাহায্যে ভূমিকাগুলির পরিচালনা সহজ হয় কারণ ব্যতিক্রমগুলি কার্যকর করা যেতে পারে।
নীচে আমি একটি দীর্ঘ চিত্র তৈরি করেছি যা আরবিএসি মডেলটি দেখায়। দাবিগুলির জন্য আমার কাছে গ্রাফিক নেই তবে আপনি কল্পনা করতে পারেন যে তারা যেখানেই থাকুক না কেন ব্যবহারকারীদের সাথে এটি সংযুক্তিযুক্ত বৈশিষ্ট্য। এছাড়াও, চিত্রটি গোষ্ঠীগুলি দেখায় না (আমার এটি কোনও সময়ে আপডেট করা দরকার)।
আশা করি এটা কাজে লাগবে.
এটি উপরে বর্ণিত আরবিএসি এর একটি ডায়াগ্রাম
@ ব্রেন্টের প্রতিক্রিয়ার ভিত্তিতে 2019 এপ্রিল, 2019-এ আপডেট করুন (আপনাকে ধন্যবাদ) ... পূর্ববর্তী উত্তরের অপ্রয়োজনীয় তথ্যসূত্রগুলি সরিয়েছে এবং @ কোডিংসফ্ট দ্বারা সরবরাহ করা "নাইট ক্লাব" রূপকটির মূল ভিত্তি ব্যাখ্যা করেছে যাতে এই উত্তরটি না করেই এই উত্তরটি বোধগম্য হয় অন্যান্য উত্তর পড়তে।
আমি এমরানের উত্তরের সাথে পুরোপুরি একমত নই
[Authorize(Roles="Sale")]নিষ্পাপ
প্রশ্নটি কীভাবে হয়
[Authorize(Roles="CustomerCreator")]এর থেকে আলাদা
[ClaimAuthorize(Permission="CanCreateCustomer")]উভয়ই যদি সমানভাবে ভাল হয় তবে আমাদের দাবি কেন দরকার?
আমি মনে করি কারণ
উপরের উদাহরণের প্রসঙ্গে আমরা বলতে পারি "গ্রাহকক্রিটর" হ'ল "অ্যাসপ.নেট্রোলপ্রাইডার" দ্বারা সরবরাহিত "ভূমিকার" ধরণের দাবি is
দাবি অতিরিক্ত উদাহরণ।
"এএএ" "এমওয়াইএক্সামসাইট ডট কম" দ্বারা সরবরাহিত "এমওয়াইএক্সামসাইট.স্কোর" টাইপের দাবি is
"গোল্ড" "এমওয়াইওয়াইএমএপ। মেম্বারশিপ টাইপ" টাইপের দাবি "এমওয়াইওয়াইম্যাপ" দ্বারা সরবরাহিত
স্বীকৃত উত্তরটি ভুমিকাটিকে একটি ভোঁতা বস্তু হিসাবে দাবি করে এবং একটি দাবিদারকে নমনীয় সরঞ্জাম হিসাবে উপস্থিত করে, তবে অন্যথায় সেগুলি প্রায় অভিন্ন বলে মনে হয়। দুর্ভাগ্যক্রমে, এই অবস্থান দাবী ধারণার ধারণাটিকে অবিচ্ছিন্ন করে এবং মূলত তাদের উদ্দেশ্য সম্পর্কে কিছুটা ভুল বোঝাবুঝির প্রতিফলন ঘটায়।
ভূমিকা বিদ্যমান এবং শুধুমাত্র একটি অন্তর্নিহিত সুযোগ মধ্যে অর্থবোধ। সাধারণত এটি একটি অ্যাপ্লিকেশন বা সাংগঠনিক সুযোগ (যেমন ভূমিকা = প্রশাসক)। অন্যদিকে দাবিগুলি যে কেউ 'তৈরি' করতে পারেন। উদাহরণস্বরূপ, গুগল প্রমাণীকরণ কোনও ব্যবহারকারীর "ইমেল" সহ দাবি উত্পন্ন করতে পারে, যাতে এই ইমেলটিকে কোনও পরিচয় যুক্ত করে। গুগল দাবি করে, অ্যাপ্লিকেশন সেই দাবিটি বুঝতে এবং গ্রহণ করতে হবে কিনা তা চয়ন করে। অ্যাপ্লিকেশন নিজেই পরবর্তীকালে "অ্যাটেন্টিকেশনমোথড" নামে একটি দাবি সংযুক্ত করতে পারে (যেমন এএসপি। নেট এমভিসি কোর আইডেন্টিটি করে) "গুগল" এর মান সহ। প্রতিটি দাবির এমন একটি সুযোগ রয়েছে যাতে দাবির বহিরাগত, স্থানীয়ভাবে বা উভয়রই অর্থ (বা প্রয়োজনের তুলনায় আরও সূক্ষ্ম দানাদার) রয়েছে কিনা তা সনাক্ত করা সম্ভব it's
মূল বিষয় হ'ল সমস্ত দাবী একটি পরিচয়ের সাথে স্পষ্টভাবে সংযুক্ত এবং একটি স্পষ্ট সুযোগ অন্তর্ভুক্ত করে। এই দাবিগুলি অবশ্যই অনুমোদনের জন্য ব্যবহার করা যেতে পারে - এবং এএসপি.নেট এমভিসি কর্তৃপক্ষের বৈশিষ্ট্যের মাধ্যমে সেটির জন্য সহায়তা সরবরাহ করে, তবে এটি দাবি বা দাবির জন্য একমাত্র বা অগত্যা এমনকি প্রাথমিক উদ্দেশ্যও নয়। এটি অবশ্যই ভূমিকাগুলির থেকে পৃথক করে না, যা স্থানীয়ভাবে স্কোপড অনুমোদনের ক্ষেত্রে ঠিক একই উপায়ে ব্যবহার করা যেতে পারে।
সুতরাং কেউ অনুমোদনের প্রয়োজনে ভূমিকা বা দাবী বা উভয়ই বেছে নিতে বেছে নিতে পারে এবং যতক্ষণ না এই ভূমিকা ও দাবী স্থানীয়ভাবে বাদ দেওয়া যায় ততক্ষণ কোনওর মধ্যে অন্তর্নিহিত সুবিধা বা অসুবিধাগুলি খুঁজে পাওয়া যায় না। তবে, উদাহরণস্বরূপ, অনুমোদন বাহ্যিক পরিচয়ের দাবির উপর নির্ভর করে, তবে ভূমিকাগুলি অপর্যাপ্ত হবে। আপনাকে বাহ্যিক দাবী গ্রহণ করতে হবে এবং এটিকে স্থানীয়ভাবে বাদ দেওয়া ভূমিকার জন্য অনুবাদ করতে হবে। এর সাথে অগত্যা কোনও ভুল নেই, তবে এটি ইন্ডিয়ারেশনের একটি স্তর প্রবর্তন করে এবং প্রসঙ্গটি বাতিল করে দেয়।
আরও বিস্তৃতভাবে, আপনাকে অ্যাট্রিবিউট-ভিত্তিক অ্যাক্সেস নিয়ন্ত্রণ (ABAC) বিবেচনা করা উচিত। আরবিএসি এবং অ্যাব্যাক দুটিই এনআইএসটি, জাতীয় মান ও প্রযুক্তি ইনস্টিটিউট দ্বারা সংজ্ঞায়িত ধারণা con অন্যদিকে, সিবিএসি হ'ল মাইক্রোসফ্ট দ্বারা চালিত এমন একটি মডেল যা অ্যাব্যাকের সাথে খুব মিল।
এখানে আরও পড়ুন:
আরবিএসি এবং সিবিএসি মধ্যে মৌলিক হ'ল:
আরবিএসি : কোনও ক্রিয়াকলাপ সম্পাদনের জন্য অনুমোদিত হওয়ার জন্য কোনও ব্যবহারকারীকে অবশ্যই কোনও ভূমিকার দায়িত্ব অর্পণ করতে হবে।
সিবিএসি : অনুমোদিত হওয়ার জন্য অ্যাপ্লিকেশন দ্বারা প্রত্যাশা অনুযায়ী ব্যবহারকারীর অবশ্যই সঠিক মান সহ একটি দাবি থাকতে হবে। দাবি-ভিত্তিক অ্যাক্সেস নিয়ন্ত্রণ রচনাটি মার্জিত এবং বজায় রাখা সহজ।
এর পাশাপাশি দাবিগুলি একটি ইস্যুকারী অনুমোদন পরিষেবাদি (সুরক্ষা পরিষেবা টোকেন এসটিএস) দ্বারা আবেদন করা হয় যা আপনার অ্যাপ্লিকেশন দ্বারা নির্ভরযোগ্য (নির্ভর পার্টি)
ভূমিকা কেবল এক ধরণের দাবি। এর মতো আরও অনেক দাবির ধরণ থাকতে পারে, উদাহরণস্বরূপ ব্যবহারকারীর নাম দাবির অন্যতম ধরণ
কোন পদ্ধতিটি সবচেয়ে ভাল তা সিদ্ধান্ত নেওয়ার আগে প্রথমে প্রমাণীকরণের জন্য কী প্রয়োজন তা বিশ্লেষণ করা গুরুত্বপূর্ণ important মাইক্রোসফ্ট ডকুমেন্টেশন থেকে নীচে বলা হয়েছে, "দাবিটি বিষয়টি কী করতে পারে তা নয় example উদাহরণস্বরূপ, আপনার কাছে চালকের লাইসেন্স থাকতে পারে, স্থানীয় ড্রাইভিং লাইসেন্স কর্তৃপক্ষ জারি করে Your আপনার ড্রাইভারের লাইসেন্সে এটির আপনার জন্ম তারিখ রয়েছে has এক্ষেত্রে দাবির নাম তারিখ-জন্মের পরে, দাবির মানটি আপনার জন্ম তারিখ হতে পারে, উদাহরণস্বরূপ 8 ই জুন 1970 এবং ইস্যুকারীই ড্রাইভিং লাইসেন্স কর্তৃপক্ষ হয়ে উঠবেন based দাবির উপর ভিত্তি করে অনুমোদনের পক্ষে এটি সবচেয়ে সহজভাবে একটি দাবির মূল্য যাচাই করে এবং অ্যাক্সেসের অনুমতি দেয় এই মানের উপর ভিত্তি করে একটি উত্স। উদাহরণস্বরূপ আপনি যদি কোনও নাইট ক্লাবে অ্যাক্সেস চান তবে অনুমোদনের প্রক্রিয়াটি হতে পারে: 6 "
এই উদাহরণ থেকে আমরা দেখতে পাচ্ছি যে দাবী-ভিত্তিক অনুমোদনের সাথে একটি নিকট ক্লাবে অ্যাক্সেস করা নাইট ক্লাবে কর্মরত কর্মীদের দ্বারা প্রয়োজনীয় যে অনুমোদনের ধরণ থেকে আলাদা হবে, এক্ষেত্রে নাইট ক্লাবের কর্মীদের প্রয়োজন হবে নাইট ক্লাব দর্শকদের জন্য নাইট ক্লাব দর্শকদের একটি সাধারণ উদ্দেশ্য হওয়ায় একটি ভূমিকা ভিত্তিক অনুমোদনের প্রয়োজন নেই, এই পরিস্থিতিতে নাইট ক্লাব দর্শকদের জন্য দাবি-ভিত্তিক অনুমোদন উপযুক্ত।
ভূমিকা ভিত্তিক অনুমোদন https://docs.microsoft.com/en-us/aspnet/core/security/authorization/roles 10/14/2016 যখন কোনও পরিচয় তৈরি করা হয় তখন এটি এক বা একাধিক ভূমিকার অন্তর্ভুক্ত হতে পারে। উদাহরণস্বরূপ, ট্রেসি অ্যাডমিনিস্ট্রেটর এবং ব্যবহারকারীর ভূমিকা সম্পর্কিত হতে পারে যেখানে স্কট কেবল ব্যবহারকারীর ভূমিকায় থাকতে পারে। এই ভূমিকা কীভাবে তৈরি এবং পরিচালনা করা হয় তা অনুমোদনের প্রক্রিয়ার ব্যাকিং স্টোরের উপর নির্ভর করে। দাবিগুলি প্রিন্সিপাল ক্লাসে আইসআইএনরোল পদ্ধতির মাধ্যমে বিকাশকারীদের ভূমিকাগুলি প্রকাশিত হয়।
দাবি-ভিত্তিক অনুমোদন https://docs.microsoft.com/en-us/aspnet/core/security/authorization/claims 10/14/2016 যখন কোনও পরিচয় তৈরি করা হয় তখন এটি কোনও বিশ্বস্ত পক্ষ দ্বারা জারি করা এক বা একাধিক দাবি অর্পণ করা যেতে পারে। দাবি হ'ল নাম মান জুটি যা বিষয়টি কী তা প্রতিনিধিত্ব করে, বিষয় কী করতে পারে তা নয়। উদাহরণস্বরূপ, আপনার কাছে চালকের লাইসেন্স থাকতে পারে, স্থানীয় ড্রাইভিং লাইসেন্স কর্তৃপক্ষ কর্তৃক প্রদত্ত। আপনার ড্রাইভারের লাইসেন্সটিতে আপনার জন্ম তারিখ রয়েছে। এক্ষেত্রে দাবির নামটি তারিখ-তারিখ জন্ম হবে, দাবির মানটি আপনার জন্ম তারিখ হবে, উদাহরণস্বরূপ 8 ই জুন 1970 এবং ইস্যুকারীই ড্রাইভিং লাইসেন্স কর্তৃপক্ষ হবে। দাবি ভিত্তিক অনুমোদনের, এর সরলতম সময়ে, একটি দাবির মান পরীক্ষা করে এবং সেই মানটির উপর ভিত্তি করে কোনও সংস্থান অ্যাক্সেসের অনুমতি দেয়। উদাহরণস্বরূপ আপনি যদি কোনও নাইট ক্লাবে অ্যাক্সেস চান তবে অনুমোদনের প্রক্রিয়াটি হ'ল:
দরজা সুরক্ষা অফিসার আপনার জন্ম দাবির মূল্য এবং আপনাকে অ্যাক্সেস দেওয়ার আগে তারা ইস্যুকারীকে (ড্রাইভিং লাইসেন্স কর্তৃপক্ষ) বিশ্বাস করে কিনা তা মূল্যায়ন করবে।
কোনও পরিচয়টিতে একাধিক মান সহ একাধিক দাবি থাকতে পারে এবং একই ধরণের একাধিক দাবি থাকতে পারে।
দাবী পদ্ধতিতে ভূমিকা পরিচালনা করাও সম্ভব।
কোনও ব্যবসায়ের ভূমিকা প্রতিফলিত করে এমন অনুমোদনের ভূমিকা তৈরির পরিবর্তে কর্মের ভূমিকা প্রতিফলিত করে এমন ভূমিকা তৈরি করুন, যেমন ক্রিয়েটকাস্টমোর, এডিট কাস্টমার, মুছে ফেলুন কাস্টমারের। প্রয়োজন অনুসারে টীকা টীকা।
কোনও ব্যক্তিকে অ্যাকশন রোলের সেটগুলিতে মানচিত্র করা সাধারণ বিষয় নয়, বিশেষত ভূমিকা তালিকা আরও বড় হওয়ার সাথে সাথে। অতএব, আপনাকে গ্রানুলারিটির (যেমন বিক্রয়, বিপণন) নিম্ন স্তরে ব্যবসায়ের ভূমিকা পরিচালনা করতে হবে এবং প্রয়োজনীয় ব্যবসায়ের ভূমিকাতে ব্যবসায়ের ভূমিকা মানচিত্র তৈরি করতে হবে। উদাহরণস্বরূপ, একটি ব্যবসায়িক ভূমিকার সাথে কোনও ব্যবহারকারীকে যুক্ত করুন এবং এটি বিদ্যমান অনুমোদনের সারণীতে প্রয়োজনীয় (ক্রিয়া) ভূমিকার জন্য এগুলি ম্যাপ করে।
এমনকি আপনি ব্যবসায়ের ভূমিকা ওভাররাইড করতে পারেন এবং সরাসরি একজন ব্যক্তিকে একটি ক্রিয়া ভূমিকার সাথে যুক্ত করতে পারেন।
আপনি ইতিমধ্যে যা কাজ করে তার উপরে ভিত্তি করে তৈরি করার কারণে আপনি বিদ্যমান অনুমোদনের প্রক্রিয়াটিকে পূর্বাবস্থায় ফিরিয়ে আনবেন না। এই পদ্ধতির প্রয়োগ করতে আপনার আরও কয়েকটি সারণী প্রয়োজন
আমি মনে করি এই প্রশ্নটির উত্তর সম্ভাব্য ডেটাবেস থেকে দেওয়া যেতে পারে। যদি আপনি খেয়াল করেন যে কীভাবে এই প্রতিস্থাপনের সাথে জড়িত সারণীগুলি আপনি নিম্নলিখিতটি পাবেন
এই টেবিলগুলির ব্যবহার নির্দিষ্ট প্রয়োজনগুলির সাথে মেলে ব্যবহারকারী / অ্যাপ্লিকেশন লাইফ টাইমের এক মুহুর্তে টুইট করা যেতে পারে।
"ক্রয়িং ম্যানেজার" (প্রধানমন্ত্রী) এর প্রাথমিক পর্যায়ে বিবেচনা করুন, আমাদের তিনটি পন্থা থাকতে পারে
অ্যাপ্লিকেশনটি 'প্রধানমন্ত্রী' কেনার অধিকার অনুদানের এক সারি দিয়ে অ্যাস্পনেট ইউসারলকে পপুলেট করে। কোনও পরিমাণ ক্রয় ক্রম জারি করতে, ব্যবহারকারীর কেবল "প্রধানমন্ত্রী" ভূমিকা প্রয়োজন।
অ্যাপ্লিকেশনটি 'পিএম' কেনার অধিকার মঞ্জুর করার জন্য এক সারি সহ এস্পনেট ইউজাররোলকে পপুলেট করে এবং এসপনেট ব্যবহারকারীকে টিওয়াইপি 'ক্রয়কৃত পরিমাণ' টাইপ এবং পরিমাণের সীমা নির্ধারণের জন্য "<1000" মান হিসাবে দাবী করে। ক্রয় আদেশ জারি করতে, ব্যবহারকারীর কাছে 'পিএম' থাকা দরকার এবং অর্ডার পরিমাণ দাবি টিওয়াইপি 'ক্রয়িংয়ের পরিমাণ' এর দাবির চেয়ে কম হওয়া উচিত।
অ্যাপ্লিকেশন টিওয়াইপি 'ক্রয় ক্রয়ের পরিমাণ' প্রকার এবং "<1000" মানের দাবির সাথে অ্যাস্পনেট ব্যবহারকারীদের দাবী করে। এই ব্যবহারকারীর জন্য দাবি ক্রয়ের পরিমাণ 'ক্রয়ের পরিমাণ' এর চেয়ে কম পরিমাণের পরিমাণ প্রদত্ত যে কোনও ব্যবহারকারী ক্রয় আদেশ জারি করতে পারেন।
যেমনটি লক্ষ্য করা যেতে পারে, ভূমিকা ভিত্তিক কঠোর অধিকারগুলির সাথে মোটা দানাযুক্ত যা সিস্টেম ব্যবহারের দৃষ্টিকোণ থেকে অ্যাপ্লিকেশন ব্যবহারকারীর জীবনকে সহজ করে তুলবে। তবে এটি ব্যবসায়ের প্রয়োজনীয়তার দৃষ্টিকোণ থেকে ব্যবহারকারীর দক্ষতা সীমাবদ্ধ করবে। অন্যদিকে দাবি ভিত্তিক খুব সূক্ষ্ম অধিকার যা প্রতিটি ব্যবহারকারীর কাছে অর্পণ করা দরকার। দাবী ভিত্তিক দাবিটি ব্যবসায়কেও সীমাবদ্ধতার দিকে ঠেলে দেবে, তবে এটি ব্যবস্থাপনাকে অত্যন্ত জটিল করে তুলবে।
ভূমিকা ভিত্তিক অ্যাক্সেস নিয়ন্ত্রণ (আরবিএসি)
আপনার সংস্থায় আপনার নিম্নলিখিত ভূমিকা থাকতে পারে
কর্মচারী
ম্যানেজার
এইচআর
লগ-ইন করা ব্যবহারকারীর ভূমিকা বা ভূমিকাগুলির উপর নির্ভর করে আপনি অ্যাপ্লিকেশনটিতে নির্দিষ্ট সংস্থানগুলিতে অ্যাক্সেসকে অনুমোদন দিতে বা নাও করতে পারেন। যেহেতু আমরা অনুমোদনের চেক তৈরি করতে ভূমিকাগুলি ব্যবহার করছি, একে সাধারণত ভূমিকা-ভিত্তিক অ্যাক্সেস কন্ট্রোল (আরবিএসি) বা ভূমিকা-ভিত্তিক অনুমোদন বলা হয়।
ভূমিকা-ভিত্তিক অনুমোদনের প্রয়োগ করতে ASP.NET কোরে, আমরা রোলস প্যারামিটারের সাথে অনুমোদনের বৈশিষ্ট্যটি ব্যবহার করি।
[Authorize(Roles = "Admin")]
public class AdministrationController : Controller
{
}দাবি ভিত্তিক অ্যাক্সেস নিয়ন্ত্রণ (সিবিএসি)
দাবী কি? একটি দাবি একটি নাম-মান জুড়ি। এটি ব্যবহারকারীর সম্পর্কে সত্যই এক টুকরো তথ্য যা ব্যবহারকারীর কী করতে পারে এবং কী করতে পারে তা নয়। উদাহরণস্বরূপ ব্যবহারকারীর নাম, ইমেল, বয়স, লিঙ্গ ইত্যাদি সমস্ত দাবি। আপনার অ্যাপ্লিকেশনটিতে অনুমোদন পরীক্ষার জন্য আপনি কীভাবে এই দাবিগুলি ব্যবহার করেন তা আপনার অ্যাপ্লিকেশন ব্যবসা এবং অনুমোদনের প্রয়োজনীয়তার উপর নির্ভর করে।
উদাহরণস্বরূপ, আপনি যদি কোনও কর্মচারী পোর্টাল তৈরি করে থাকেন তবে লিঙ্গ দাবি মান যদি মহিলা থাকে তবে আপনি লগ-ইন করা ব্যবহারকারীকে মাতৃত্বকালীন ছুটির জন্য আবেদনের অনুমতি দিতে পারেন। একইভাবে, আপনি যদি একটি ইকমার্স অ্যাপ্লিকেশন তৈরি করে থাকেন তবে বয়স দাবি মান 18 এর চেয়ে বেশি বা তার সমান হলে লগ-ইন করা ব্যবহারকারীকে অর্ডার জমা দেওয়ার অনুমতি দিতে পারেন।
দাবিগুলি নীতি ভিত্তিক। আমরা একটি নীতি তৈরি করি এবং সেই নীতিতে এক বা একাধিক দাবি অন্তর্ভুক্ত করি। এরপরে দাবী ভিত্তিক অনুমোদন বাস্তবায়নের জন্য নীতিটি অনুমোদনের বৈশিষ্ট্যের নীতি প্যারামিটারের সাথে ব্যবহৃত হয়।
[Authorize(Policy = "DeleteRolePolicy")]
public async Task<IActionResult> DeleteRole(string id)
{
}