❇️ کنترل سطح دسترسی پویا و Permission-based

چند وقت پیش یکی از دوستان سوال پرسیده بودند که چطور میتونیم سطح دسترسی کاربر رو به اکشن های دلخواه، محدود کنیم. اتفاقا چند سال پیش همین نیاز رو خودمم داشتم و به این صورت هندلش کردیم که :

هر کاربر میتونه N تا Role داشته باشه و هر Role هم N تا پرمیژن داره
پرمیژن ها در واقع Fullname اکشن هایی هستند که کاربر بهشون دسترسی داره مثلا
MyProject.HomeController.Index
مشخص میکنه کاربر به این اکشن دسترسی داره و وجود نام کامل متد باعث میشه مشکل هم نام بودن اکشن ها و کنترولر ها در پروژه های Microservice رو هم نداشته باشیم

مدیریت این قضیه هم کاملا توسط Reflection و Caching خیلی شیک انجام میشد و نیازی پرفرمنس بسیار خوبی هم داشت با توجه به اینکه تعداد کاربرانمونم زیاد بود، ضمن اینکه هیچ گونه کد نویسی ویا چک کردن سطح دسترسی لازم نبود توسط برنامه نویس انجام بشه و همگی در یک ActionFilter سراسری هندل میشد

قابلیت دیگه ای هم که نیاز بود و بهش اضافه کردیم بحث Group کردن اکشن های مرتبط بود. مثلا کاربری که دسترسی به ویرایش یک سند داره عملا به 3 اکشن Detail, Edit(Get) , Update(Post) x باید دسترسی داشته باشه، درنتیجه میتونستیم با اضافه کردن یک پرمیشن، 3 اکشن رو دسترسی داشته باشه

حتی واسه نیاز های پیچیده تر میتونین بحث Include و Exclude کردن یک یا چند پرمیژن رو از یک Role هم اضافه کنید. مثلا یک کاربر نقش Writer داره ولی... به یک اکشن از Report هم دسترسی داره (Include) و یا به یک اکشن خاص از نقش Writer نباید دسترسی داشته باشه (Exclude)
سلوشن بالا تمامی نیاز های مارو به خوبی برطرف کرد و کاملا راضی بودیم، برای پیاده سازیش هم میتونین از Identity یا هر پیاده سازی دلخواه برای احراز هویت استفاده کنید

🔸در کل ما 3 نوع کنترل سطح دسترسی داریم
سطح Api level (کنترل دسترسی به یک action/api خاص)
سطح Operation level (کنترل دسترسی به یک فرایند/بیزنس لاجیک خاص)
سطح Data level (کنترل دسترسی برای دیتای دریافتی از دیتابیس)

روش بالا برای کنترل دسترسی در سطح Action (همون Api level) هست و برای نیاز های دیگه کنترل دسترسی مثل کنترل دسترسی به یک فرایند خاص (Operation level) میتونین از مکانیزم ACL (مخفف access control list) استفاده کنید
برای کنترل دسترسی در سطح Data (همون Data level) برای کوئری گرفتن هم از Global Query Filter خود EF Core استفاده کنید
https://long2know.com/2017/05/entity-framework-multitenancy/
https://trailheadtechnology.com/entity-framework-core-2-1-automate-all-that-boring-boiler-plate/

🔹یه رویکرد دیگه که به نظر اصولی تر هم هست ولی یه کم تخصصی تره
بحث کنترل دسترسی در سطح Service ها توسط تکنیک AOP هست

مثلا این مقاله با CastleWindsor اومده قبل از اجرا شدن متد های سرویس، دسترسی کاربر رو چک کرده
https://lukemerrett.com/aop-in-castle-windsor/

از مزایای این روش میشه به این اشاره کرد که شما میتونین لایه سرویس (همون منطق تجاری پروژه) رو توی پروژه های دیگه هم به صورت مستقل استفاده کنید و نگران سطح دسترسی نباشید چون همش تو همون لایه داره چک میشه

🔸مدیریتش تو لایه Repsitory هم یک روش مرسوم هست
عملا استفاده از روش repository و Global Query Filter داره یک کار رو انجام میده
هر دو با شرط گذاشتن روی کوئری ها، دسترسی رو چک میکنن تنها تفاوت بینشون اینه که Global Query Filter این کار رو به صورت اتوماتیک انجام میده و دیگه لازم نیست موقع کوئری نوشتن حواسمون باشه که شرط فیلتر رو هم بگذاریم

و مزیتش دیگه اش هم اینه که موقع Explicit Loading (همون Include) و
حتی موقع Eager Loading (توسط LoadCollection و LoadReference) هم این موضوع به صورت خودکار چک میشه. توی EF 6 نبود این ویژگی. توی EF Core 2.0 اضافه شد

🔰این سری مقاله رو هم پیشنهاد میکنم بخونین، توضیحات خوبی در مورد روش های کنترل سطح دسترسی داده

Part 1: A better way to handle authorization in ASP.NET Core
https://bit.ly/2KaAo0q

Part 2: Handling data authorization in ASP.NET Core and Entity Framework Core
https://bit.ly/2KbA9SG

Part 3: A better way to handle ASP.NET Core authorization – six months on
https://bit.ly/2K8Z6hU

Part 4: Building a robust and secure data authorization with EF Core
https://bit.ly/2K885zH

#سطح_دسترسی #permission
___________________