چرا در این پروژه از موجودیت‌های custom استفاده شده بجای موجودیت‌های Identity مثل UserIdentity؟ کلا چرا از Identity استفاده نشده اینجا؟

1. دلیل خاصی داره یا خیر؟
2. مزایا معایبی که ممکنه داشته باشه چیا هستند؟
در کنار این راه حل که با ایونت‌ها هندل میشه و عنوان کردین، راه زیر هم جهت ریدایرکت به اکشن مد نظر ما، پیشنهاد شده:

[HttpGet]
[Route("signin")]
public async Task SignIn()
{
    if (!User.Identity.IsAuthenticated)
    {
        await HttpContext.ChallengeAsync("oidc", new AuthenticationProperties
        {
            RedirectUri = "/YourController/YourAction",
        });
    }
}
public IActionResult Logout()
{
    return SignOut(new AuthenticationProperties { RedirectUri = "/YourController/YourAction" }, "Cookies", "oidc");
}

مهدی م مهدی م
امن سازی برنامه‌های ASP.NET Core توسط IdentityServer 4x - قسمت ششم - کار با User Claims
‫۴ سال و ۵ ماه قبل، پنجشنبه ۷ فروردین ۱۳۹۹، ساعت ۱۷:۳۱
کلا صحبت من توی روش اول یا RBAC هست الان؛ یکسری claim‌ها رو میشه بصورت مشترک و جامع برای کاربر داشت و برای همه کلاینت‌ها یک معنی میده. مثل profile, address, ... یک کاربر مشترک هست. این درست. اما برای حالتی که چندین کلاینت داریم و هرکدوم claim‌های خاص خودشون رو نیاز دارن. یا بطور خاص role های خودشون رو دارن. مثلا کاربری با نام علی در کلاینت یک (سامانه حقوق و دستمزد)، نقش‌های زیر رو داره که فقط برای کلاینت یک معنی میده:
  • ثبت کننده اطلاعات
  • کاربر عادی
همین کاربر، در کلاینت دو (سامانه اتوماسیون اداری) نقش‌های زیر رو داره که فقط برای کلاینت دو معنی میده:
  • مدیر منطقه یک
  • کاربر عادی
  • تنظیم کننده گردش کار اداری
متوجه این قضیه هستم که میشه سمت identityServer برای هر کلاینت، claim‌های مجاز خودش رو بهش دسترسی داد و منتسب کرد. ولی در شرایطی که مثلا 50 تا سامانه (کلاینت) مختلف، 100 نقش مختلف برای هندل کردن بیزینس خودشون دارن، آیا باید تمام این 100 نقش رو در سمت identityServer تعریف کنیم و به هر کلاینت، نقش‌های مجاز خودش رو منتسب کنیم و هر زمان که یک سامانه، یک نقش جدید نیاز داشته باشه، باز بیایم و در IdentityServer اون رو تعریف کنیم؟ یعنی راه درست همینه؟
سوالم در نهایت اینه:
1. حالا به این شکل، آیا باید تمام این نقش‌ها در سمت IdentityServer در claimها (role claim) تعریف بشه؟
2. هر کلاینت که چند وقت بعد، نیاز داره یک role جدید دیگه در بیزینس داخلی خودش داشته باشه، باید سمت IdentityServer بیاد و اضافه کنه اون role رو تحت عنوان یک role claim جدید؟ و سپس، همین role رو به کاربرایی که مد نظرش هست، اعطا کنه؟
دو قسمت 11 و 12 رو بررسی کردم. ولی من تامین کننده خارجی گوگل و فیسبوک رو توی صورت مسئله خودم ندارم و گویا روند callback توی اون قضیه با صورت مسئله ای که من مد نظرم هست متفاوته. در واقع چیزی که من میخوام اینه که بعد از اینکه کاربر در IdentityServer لاگین کرد و برگشت به کلاینت، بتونم یکسری کارهایی که میخواهم رو انجام بدم توی اون کلاینت. یعنی کلاینت، بتونه این ایونت رو هندل کنه و کارهایی انجام بده بسته به سیاست‌ها و منطق تجاری داخلی خودش.
در صورتی که بخواهیم idp، کاربر رو بعد از 
1. لاگین
2. لاگ اوت
به url مورد نظر ما ریدایرکت کنه، به چه صورت باید عمل کنیم که اصولی هم باشه؟ آیا از ایونت های odic باید استفاده کنیم؟

جدای از signin-oidc , signout-callback-oidc که در flow پیش فرض oidc تعریف شده و در پشت صحنه توسط middle ware ِخودش هندل میشه این ریدایرکت ها، چیزی که من میخام اینه که بعد از لاگین شدن توی idp و برگشت به کلاینت، بتونم یکسری کارها رو انجام بدم. مثلا با استفاده از اکسس توکن، اطلاعات کاربر رو از end point ِش بگیرم و ... .
به شیوه زیر که عمل میکنم : 
  .AddOpenIdConnect("oidc", config =>
               {
                   config.CallbackPath = "/home/ExternalLoginCallBack";
آدرس return url رو در نوار آدرس میبینم که بعد از لاگین و در صفحه consent ست شده، و درخواست POST میزنه به این آدرس، ولی به اکشن مد نظرم نمیرسه هیچ وقت!
به چه صورت باید عمل کرد؟
بعد از رجیستر کاربر در idp، به چه صورت به کلاینت بگردیم. بهترین راهش چیه؟ 
مثلا ما idp رو روی دامین http://idp.mydomain.com مستقر کردیم و یک کلاینت رو در آدرس http://client1.mydomain.com داریم، حالا میخواهیم بعد از اینکه کاربر روی idp رجیستر کرد اطلاعات خودش رو، به دامین کلاینت برگرده. به چه صورت باید عمل کنیم؟

توی کنترلر UserRegistrationController
 جایی که قراره ریدایرکت انجام بشه:
            // continue with the flow     
            if (_interaction.IsValidReturnUrl(model.ReturnUrl) || Url.IsLocalUrl(model.ReturnUrl))
            {
                return Redirect(model.ReturnUrl);
            }
و داخل سورس is4  رو هم که نگاه کردم، فقط اجازه میده که روی دامین لوکال خودش باشه! فلسفه‌ی این چیه؟ و چجوری میشه موردی که اول گفتم رو حل کرد؟
ممنون
من میخواهم IDP خودمون رو با کمک is4 مستقر کنم. مشکل اینه که سامانه‌ها و نرم افزارهایی هستند که خودمون ننوشتیم و نمینویسیم، بلکه توسط پیمانکاران مختلف (با معماری‌های مختلف) طراحی شدن و هر کدوم بصورت جزیره ای (احراز هویت مستقل دارن ولی مثلا کد ملی بین همه مشترکه) دارن کار میکنن با یوزرهای خودشون. میخواهیم در نهایت بهشون یک فایل راهنما بدیم که طبق اون دستورالعمل (و بر اساس client id , client secret خودشون)، هرکدوم از اونها به idp ما، متصل بشن جهت احراز هویت و گرفتن اطلاعات اصلی کاربران (مباحث کانورت اطلاعات و حواشی اینچنین رو کار ندارم و فرض میکنیم مشکلی نیست)
1: با توجه به اینکه IS4 بر اساس openid connect + oauth2 پیاده سازی شده و مورد تایید هم می‌باشد و بر اساس ارسال درخواست‌ها روی front channel و back channel هست، آیا محدودیت هایی برای تنوع بسترهای مختلف بعنوان کلاینت هست یا خیر؟
مثلا برای
php, oracle adf, asp.net web forms, asp.net mvc, ...

2: چه مقدار تغییرات خواهند داشت؟ فقط روال ورود و خروج رو باید تغییر بدن؟ با توجه به اینکه مثلا روال user, role, user-role کلاسیک خودشون رو دارن جهت authorization لوکال منابع داخلیشون
3: ما فقط میخواهیم از is4 بعنوان مخزن مشترک " اطلاعات اصلی" کاربران و درگاه ورود/خروج مشترک استفاده کنیم. یعنی :
  • در ابتدا کاربر میاد به idp و رجیستر میکنه تا بتونه از سامانه‌های مختلف متصل به idp استفاده کنه
  • کاربر جهت لاگین در کلاینت (سامانه)، هدایت میشه به idp (این کار توسط همون کلاینت انجام میشه)
  • بعد از احراز هویت در idp، کاربر ریدایرکت میشه به همون برنامه (کلاینت)
  • حالا وقتی برمیگرده به کلاینت، اون برنامه، "اطلاعات اصلی" کاربر (که از idp برگشته) رو داره
  • کاربر رو در دیتابیس لوکال خودش جستجو میکنه (مثلا بر اساس subject_id)؛ یا پیداش میکنه و یا اگه کاربر در دیتابیس لوکال اون سامانه وجود نداشته باشه، بعنوان کاربر جدید درجش میکنه
  • با کاربر مرحله قبل، در سامانه لوکال لاگین میکنه
  • دیگه برنامه لوکال (کلاینت) با idp کاری نداره. چون سیاست داخلی خودش رو داره جهت هندل کردن session‌ها و دسترسی‌ها بر اساس role‌های لوکال در اون برنامه. تا زمانی که بخواد کاربر logout کنه.
  • برای logout، کاربر در کلاینت لاگ اوت و سپس در سمت idp لاگ اوت میشه و مجددا به homepage سامانه لوکال ریدایرکت میشه
آیا سناریو بالا درسته؟
4: با توجه به توضیحات مطروحه، برای این تنوع کلاینت‌ها که بالاتر عنوان کردم، باید از hybrid flow استفاده کنیم یا authorization code + PKCE؟ یا باز برای هر کلاینت جداگانه بررسی و تصمیم گیری کنیم بسته به نوع مکانیزمش