কেউ দয়া করে ব্যাখ্যা করতে পারেন, নতুন এএসপি.নেট আইডেন্টিটি কোরে দাবি পদ্ধতিটি কী বোঝায়?
আমি দেখতে পাচ্ছি, একটি আছে AspNetUserLogins টেবিল, যা ধারণ করে UserId, LoginProviderএবং ProviderKey।
তবে, আমি কখন ডেটা যুক্ত করা হয় সে সম্পর্কে কোনও তথ্য বুঝতে বা খুঁজে পেতে পারি না AspNetUserClaims টেবিলের এবং এই টেবিলটি কোন পরিস্থিতিতে ব্যবহার করা হয় ?
উত্তর:
নতুন এএসপি.নেট আইডেন্টিটি কোরে দাবী প্রক্রিয়াটি কী বোঝায়?
দুটি সাধারণ অনুমোদনের পন্থা যা ভূমিকা এবং দাবির উপর ভিত্তি করে।
ভূমিকা-ভিত্তিক সুরক্ষা
একজন ব্যবহারকারী এক বা একাধিক ভূমিকার জন্য নিযুক্ত হন যার মাধ্যমে ব্যবহারকারী অ্যাক্সেসের অধিকার পান। এছাড়াও, কোনও ভূমিকে কোনও ব্যবহারকারীকে নিয়োগের মাধ্যমে, ব্যবহারকারী তত্ক্ষণাত্ সেই ভূমিকার জন্য নির্ধারিত সমস্ত অ্যাক্সেস অধিকার পেয়ে যায় gets
দাবি-ভিত্তিক সুরক্ষা
দাবি-ভিত্তিক পরিচয় দাবিগুলির সেট। দাবি হ'ল একটি বিবৃতি যা কোনও সত্তা (একটি ব্যবহারকারী বা অন্য কোনও অ্যাপ্লিকেশন) নিজের সম্পর্কে তৈরি করে, এটি কেবল একটি দাবি। উদাহরণস্বরূপ দাবি তালিকায় ব্যবহারকারীর নাম, ব্যবহারকারীর ইমেল, ব্যবহারকারীর বয়স, কোনও ক্রিয়াকলাপের জন্য ব্যবহারকারীর অনুমোদন থাকতে পারে। ভূমিকা-ভিত্তিক সুরক্ষায় কোনও ব্যবহারকারী সরাসরি প্রয়োগের শংসাপত্রগুলি উপস্থাপন করে। একটি দাবি-ভিত্তিক মডেলটিতে, ব্যবহারকারী দাবী উপস্থাপন করে অ্যাপ্লিকেশনটির শংসাপত্রগুলি না। ব্যবহারিক মূল্য আছে বলে দাবি করার জন্য, এটি অবশ্যই এমন একটি সত্তা থেকে আসা উচিত যা অ্যাপ্লিকেশন বিশ্বাস করে।
দাবিগুলির উপর ভিত্তি করে সুরক্ষা মডেলগুলিতে ঘটে যাওয়ার ক্রমটি নীচের পদক্ষেপে চিত্রিত করে:
তবে, আমি এখনও কোনও তথ্য বুঝতে এবং সন্ধান করতে পারি না, যখন ডেটা এস্পনেটসুউসারকলামগুলিতে যুক্ত হয় এবং এই টেবিলটি কী পরিস্থিতিতে ব্যবহার করে?
যখন আপনি এমন পরিস্থিতিতে রয়েছেন যে কোনও ভূমিকা-ভিত্তিক সুরক্ষা ব্যবহার করা হয়নি এবং আপনি দাবি-ভিত্তিক সুরক্ষা ব্যবহার করা বেছে নিয়েছেন, আপনাকে অ্যাসপনেটসুজারস্লেমস সারণিটি ব্যবহার করতে হবে। এএসপি.নেট পরিচয় সম্পর্কিত কীভাবে দাবিগুলি ব্যবহার করবেন তার জন্য আরও তথ্যের জন্য নীচের লিঙ্কটি দেখুন।
http://kevin-junghans.blogspot.com/2013/12/using-claims-in-aspnet-identity.html
হালনাগাদ
ভূমিকা-ভিত্তিক সুরক্ষা এবং কখন দাবি-ভিত্তিক ব্যবহার করতে হবে? আপনি দয়া করে কয়েকটি উদাহরণ লিখতে পারেন?
খুব কার্যকর পরিস্থিতি নেই যেখানে আপনি ভূমিকা ভিত্তিক বা দাবি-ভিত্তিক সুরক্ষা ব্যবহার করবেন না বা ব্যবহার করবেন না, এমন ক্ষেত্রে নয় যেখানে আপনি বি এর পরিবর্তে এ ব্যবহার করবেন case
তবে, দাবি-ভিত্তিক অ্যাক্সেস নিয়ন্ত্রণ মূল ব্যবসায়ের যুক্তি থেকে অনুমোদনের নিয়মগুলিকে আরও ভালভাবে পৃথক করার অনুমতি দেয়। অনুমোদনের নিয়মগুলি পরিবর্তিত হলে মূল ব্যবসায়ের লজিক প্রভাবিত হয় না। এমন পরিস্থিতিতে থাকবে যেখানে আপনি দাবি-ভিত্তিক পদ্ধতির ব্যবহার পছন্দ করতে পারেন।
কখনও কখনও দাবি প্রয়োজন হয় না। এটি একটি গুরুত্বপূর্ণ অস্বীকৃতি। অভ্যন্তরীণ অ্যাপ্লিকেশনগুলির একটি হোস্ট সংস্থাগুলি দাবি দ্বারা সরবরাহিত অনেক সুবিধা অর্জন করতে ইন্টিগ্রেটেড উইন্ডোজ প্রমাণীকরণ ব্যবহার করতে পারে। অ্যাক্টিভ ডিরেক্টরি ব্যবহারকারী পরিচয়গুলি সংরক্ষণ করার জন্য দুর্দান্ত কাজ করে এবং কার্বেরোস উইন্ডোজের একটি অংশ হওয়ায় আপনার অ্যাপ্লিকেশনগুলিতে বেশি প্রমাণীকরণের যুক্তি অন্তর্ভুক্ত করতে হবে না। আপনার নির্মিত প্রতিটি অ্যাপ্লিকেশন যতক্ষণ না ইন্টিগ্রেটেড উইন্ডোজ প্রমাণীকরণ ব্যবহার করতে পারে ততক্ষণ আপনি ইতিমধ্যে আপনার পরিচয় ইউটোপিয়ায় পৌঁছেছেন। যাইহোক, উইন্ডোজ প্রমাণীকরণ ছাড়া আপনার অন্য কিছু প্রয়োজন হতে পারে এমন অনেকগুলি কারণ রয়েছে। আপনার কাছে ওয়েব মুখযুক্ত অ্যাপ্লিকেশন থাকতে পারে যা আপনার উইন্ডোজ ডোমেনে অ্যাকাউন্ট নেই এমন লোকদের দ্বারা ব্যবহৃত হয়। আর একটি কারণ হতে পারে যে আপনার সংস্থাটি অন্য সংস্থার সাথে মিশে গেছে এবং আপনি ' দুটি উইন্ডো অরণ্য জুড়ে প্রমাণীকরণ করতে সমস্যা হচ্ছে যার বিশ্বাসের সম্পর্ক নেই (এবং কখনও হতে পারে না)। সম্ভবত আপনি অন্য কোনও সংস্থার সাথে পরিচয় ভাগ করতে চান যার নন.নেট ফ্রেমওয়ার্ক অ্যাপ্লিকেশন রয়েছে বা আপনার বিভিন্ন প্ল্যাটফর্মগুলিতে চলমান অ্যাপ্লিকেশনগুলির মধ্যে পরিচয় ভাগ করতে হবে (উদাহরণস্বরূপ, ম্যাকিনটোস)। এগুলি কেবলমাত্র কয়েকটি পরিস্থিতি যেখানে দাবী-ভিত্তিক পরিচয় আপনার পক্ষে সঠিক পছন্দ হতে পারে।
আরও তথ্যের জন্য, দয়া করে http://msdn.microsoft.com/en-us/library/ff359101.aspx দেখুন
The user presents the credentials to the issuing authority that the RP application trusts.আপনি এই কর্তৃপক্ষ / জারিকারী হিসাবে কী ব্যবহার করতে পারেন? কিছু উদাহরণ সুন্দর হবে। আমি এমএসডিএন সাইটে নিবন্ধটি লাল করেছি (আপনি যে লিঙ্কটি সরবরাহ করেছেন) তবে তারা কেবল একটি উদাহরণের তালিকা দেয়: এডিএফএস, অন্য কোনও বিকল্প আছে কি? এই তথ্য কোথাও খুঁজে পাচ্ছি না। :(
@ লিন উপরে কি বলেছে তা সম্পর্কে আরও যুক্ত করুন। আমি বিশেষভাবে প্রশ্নটি উল্লেখ করছি:
ভূমিকা-ভিত্তিক সুরক্ষা এবং কখন দাবি-ভিত্তিক ব্যবহার করতে হবে? আপনি দয়া করে কয়েকটি উদাহরণ লিখতে পারেন?
এমন একটি ক্ষেত্রে বিবেচনা করুন যেখানে আপনার কাছে ক্লকিং সিস্টেম রয়েছে যেখানে আপনার কাছে একজন প্রযুক্তিবিদ এবং পরিচালক রয়েছে। প্রতি সপ্তাহের শেষে, টেকনিশিয়ানকে অবশ্যই সেই ক্লকিংয়ের তথ্য সহ প্রতিবেদনগুলি সাজিয়ে রাখতে হবে যাতে সেই সপ্তাহের জন্য কয়েক ঘন্টা কাজের কারিগর কাজ করেছিলেন, যা একীভূত হয় এবং বেতনের দ্বারা ব্যবহৃত হয়। চূড়ান্ত প্রতিবেদন দাখিল করার আগে এই জাতীয় সিস্টেমগুলিতে প্রায়শই সংশোধন বা সংশোধন করতে হয়, কারণ আপনি আপনার কর্মীদের অতিরিক্ত অর্থ প্রদান বা বঞ্চিত করতে চান না। আপনি Role-Basedম্যানেজার এবং টেকনিশিয়ানদের জন্য একটি Manager Roleএবং একটি তৈরির মাধ্যমে একটি পদ্ধতির ব্যবহার করতে পারেন Technician Role। কিন্তু Manager Roleকারিগরদের ক্লকিং তথ্য অ্যাক্সেস এবং সম্পাদনা করার ক্ষমতা সহকারে এটিই। অন্যদিকে, আপনি থাকতে পারেনTechnician Roleএই তথ্য অ্যাক্সেস করতে এই ক্ষমতা ছাড়া। তবে মজার অংশটি এখানে; একজন পরিচালক কোনও দাবি করতে পারে এবং কোনও প্রযুক্তিবিদকে ক্লকিং সিস্টেমগুলিতে অ্যাক্সেস করতে এবং প্রতিবেদন করতে দেয়। সুতরাং একটি দাবি সম্পাদনা ছাড়াই অ্যাক্সেসের জন্য করা যেতে পারে বা অ্যাক্সেস এবং সম্পাদনা ক্ষমতা সহ করা যেতে পারে।
এটি আরও বলার মতো, ওয়েল, ম্যানেজার হিসাবে ডিফল্টরূপে আমি এমন কিছু তথ্য অ্যাক্সেস করতে পারি যা আমার প্রযুক্তিবিদ অ্যাক্সেস করতে পারে না। তবে আমি কি সবসময় অফিসের আশেপাশে থাকি না? আমি কী করব যাতে আমি আশেপাশে না থাকলেও সে কাজটি করতে পারে? এটি সমাধানের জন্য ব্যবস্থাপকদের কিছু নির্দিষ্ট তথ্য অ্যাক্সেস না করে লোকদের জন্য দাবি তৈরি করার বৈশিষ্ট্যটি সিস্টেমের কাছে থাকতে পারে। আমরা আমাদের ইআরপি সিস্টেমে প্রায়শই এগুলি দেখতে পাই। কোনও ব্যবহারকারী কিছু মডিউল অ্যাক্সেস ছাড়াই এবং যখন তারা পদোন্নতি পান তারা ইআরপি সিস্টেমের আরও মডিউলগুলিকে অনুমতি প্রদান করছেন, কখনও কখনও একই ব্যবহারকারীর ভূমিকা রাখে।
এটি দাবী এবং ভূমিকা আরও বোঝার জন্য বিবেচনা করতে পারেন এমন একটি উদাহরণ।
এএসপি.নেট পরিচয় দুই ধরণের প্রমাণীকরণ রয়েছে।
আপনি হয় সেগুলির মধ্যে একটি বা উভয় একই সময়ে ব্যবহার করতে পারেন। আপনার যখন খুব সংজ্ঞায়িত জিনিস থাকে তখন রোল ভিত্তিক ব্যবহার করুন। উদাহরণস্বরূপ আপনি দুটি ভূমিকা শিক্ষক এবং শিক্ষার্থী তৈরি করেন। কেবল শিক্ষকই সাবজেক্ট যুক্ত করতে পারবেন। সুতরাং আপনি সেই ব্যবহারকারীদের জন্য শিক্ষকের ভূমিকা অর্পণ করেছেন যাদের আপনি বিষয়গুলি যুক্ত করার অ্যাক্সেস পেতে চান।
দাবি ভিত্তিক আরও নমনীয়। মনে করুন আপনার কোনও চাহিদা আছে কিছু শিক্ষার্থী সাবজেক্ট যুক্ত করতে পারবেন। এই ক্ষেত্রে আপনাকে আরও একটি ভূমিকা তৈরি করতে হবে যারা শিক্ষার্থী হতে পারে এবং সাবজেক্ট যুক্ত করতে অ্যাক্সেস করতে পারে। তবে আপনি যদি দাবি ভিত্তিক ব্যবহার করেন তবে এটি খুব সহজ হবে। অ্যাডসউবজেক্টের মতো দাবী তৈরি করুন এবং যে কোনও ব্যবহারকারীর কাছে আপনি অবিজেক্ট যুক্ত করতে চাইলে এটি নির্ধারণ করুন to