احمد نواصری احمد نواصری
Claim Based Identity
اندازه‌ی قلم متن
تخمین مدت زمان مطالعه‌ی مطلب: دو دقیقه
بنده در حال توسعه‌ی یک CMS هستم و این کار را برای یادگیری MVC انجام میدم. الان هم تقریبا رسیدم به اواخر کار و انشالله اگه کار تمام شد، نرم افزار را به صورت سورس باز منتشر می‌کنم. الان رسیدم به قسمت مدیریت کاربران. همانطور که می‌دانید ASP.NET در نسخه‌های جدید خودش بر خلاف نسخه‌های قدیمی که از SQL Membership استفاده می‌کرد الان از سیستم Identity بهره می‌برد، که انشالله در نوشتارهای بعدی به موضوع Identity به تفصیل خواهیم پرداخت. در حقیقت  سیستم Identity یک نوع Claim Based Identity هست. اما حالا ببینیم که این Claim چی هست؟ اما قبل از آن یک سری اصطلاحات را که به درک بهتر مفهوم کمک می‌کند، باید تعریف کنیم:

Relying Party (RP) = Application

Service Providers (SP) = Application 

RP  یا SP یک Application می‌باشد که از Claim استفاده می‌کند. واژه‌ی Relying Party بدین دلیل انتخاب شده که Application روی یک Issuer به منظور تامین اطلاعات در مورد یک Identity تکیه می‌کند.

Subject = User

Principal = User

واژه‌ی Subject یا Principal در حقیقت یک User می‌باشد. این واژه زمانی معنا پیدا می‌کند که شما به User به عنوان یک Subject برای کنترل دسترسی، شخصی سازی (Personalization) و ... بنگرید. در Net Framework. به جای Subject از Principal استفاده می‌شود.

Security Token Service (STC) = Issuer

از دید فنی، STC یک رابط درون یک Issuer می‌باشد که درخواست‌ها (Request) را تأیید و اقدام به ساخت Issues Security Token (توکن‌های مسائل امنیتی) می‌نماید. توکن‌های مسائل امنیتی شامل یک سری Claim می‌باشند.

Identity Provider (IDP) = Issuer 

تامین کننده Identity یک Issuer یا Token Issuer می‌باشد که وظیفه‌ی تعیین اعتبار (Validation) کاربر مانند نام کاربری، رمز عبور و ... را بر عهده دارد.

Active Client = Smart or rich Client

Passive Client = Browser 

یک Active Client می‌تواند از یک کتابخانه‌ی پیچیده مانند WCF به منظور پیاده سازی پروتکل‌هایی که بتوانند یک Security Token را درخواست و پاس دهند، استفاده نمایند. به منظور پشتیبانی از مرورگرهای مختلف، سناریوهای passive از پروتکل‌های ساده‌تری به منظور درخواست و پاس دادن یک Security Token که بر روی پروتکل Http تکیه دارد استفاده می‌کند (Http Post - Http Get).

و اما Claim چیست؟

در حقیقت Claim عبارتست از یک بیانیه یا شرح که یک Subject در مورد خودش یا Subject دیگری می‌سازد. این بیانیه می‌تواند در مورد یک نام، هویت، کلید، گروه، حق دسترسی و یا یک قابلیت باشد. Claim‌ها بوسیله یک Provider صادر و سپس بسته بندی (Package) شده و بوسیله‌ی یک Issuer صادر می‌شوند که این Issuer عموما با نام Security Token Service شناخته می‌شود. 

به منظور آشنایی با این مبحث میتوانید به اینجا و اینجا مراجعه نمایید.

این نوشتار مقدمه‌ای بود بر مباحث ASP.NET Identity. بنده در حال ترجمه‌ی سه فصل آخر کتاب Pro ASP.NET Mvc 5 Platform که اختصاص به مبحث Identity دارد هستم. فصل 13 تقریبا تمام شده و انشالله بزودی آن‌را منتشر میکنم.

‫۹ سال و ۳ ماه قبل، شنبه ۶ تیر ۱۳۹۴، ساعت ۱۸:۵۵
۸۲۴۷
۴
MVCSecurityASP.NET Identity
مطالب مشابه
  • #
    حامد حاجیلو حامد حاجیلو
    ‫۵ سال و ۹ ماه قبل، سه‌شنبه ۱۳ آذر ۱۳۹۷، ساعت ۲۰:۴۸
    ترجمه این کتاب را چه وقتی چاپ می‌کنید؟
  • #
    محمد کاظمی م محمد کاظمی م
    ‫۵ سال و ۴ ماه قبل، یکشنبه ۱ اردیبهشت ۱۳۹۸، ساعت ۱۷:۰۸
    سلام؛ بنده یک سیستم نوشتم و کامل کار می‌کنه ولی بعد از چندبار لاگین یکدفعه سیستم ارور می‌ده و دیگه از اون مرورگر نمی‌تونم هیچ صفحه ای از اون سایت رو باز کنم. حتی صفحه اصلی سایت یا صفحه لاگین سایت که بنده claim‌ها رو بررسی نمی‌کنم. اگر مرورگر رو عوض کنم و یا از همون مرورگر با یک اکانت دیگه وارد سایت بشم، سیستم بدون هیچ مشکلی صفحه لاگین رو باز می‌کنه و می‌تونم یوزر و پسورد رو وارد کنم تا وارد سایت بشم. اما اگر یوزر پسورد رو بزنم و درست باشه برای اون مرورگر هم همین مشکل پیش میاد. نمی‌دونم مشکل از چیه و به حالت دیفالت claim‌‌ها فقط یوزر نیم و دسترسی‌ها رو اضافه کردم و هیچ دستکاریه دیگه ای انجام ندادم. توی سیستم لوکال اگر دیتابیس رو حذف کنم و دوباره ایجادش کنم، تا یک مدتی سیستم درست کار می‌کنه ولی بعد از یک مدت کوتاهی دوباره همین مشکل براش پیش میاد. 

    • #
      وحید نصیری وحید نصیری
      ‫۵ سال و ۴ ماه قبل، یکشنبه ۱ اردیبهشت ۱۳۹۸، ساعت ۱۷:۲۱
      - بعد از لاگین، claims و خیلی موارد دیگر به کوکی(های) دومین جاری شما اضافه می‌شوند. اگر تعداد زیادی claim را تعریف کرده باشید یا اطلاعات زیادی را در کوکی ذخیره کنید، پیام طولانی بودن هدر یا تصویر فوق (request too long) را از طرف برنامه یا وب سرور دریافت خواهید کرد؛ چون جمع تمام این کوکی‌ها به صورت خودکار، با هر درخواست، به سمت سرور ارسال می‌شوند و مشکل بیش از اندازه طولانی بودن درخواست را ایجاد می‌کنند.
      - برای اینکه با مرورگر فعلی مجددا بتوانید با سایت کار کنید، فقط یک راه حل را دارید: به developer tools -> application -> cookies مرورگر مراجعه کرده و تمام کوکی‌های دومین و آدرس جاری را پاک کنید. البته این راه حل موقت است و اگر اندازه‌ی کوکی‌ها را مدیریت نکنید، دوباره تکرار می‌شود.
      - در ASP.NET Identity Core راه حلی برای کاهش اندازه‌ی کوکی‌های برنامه و انتقال آن‌ها به بانک اطلاعاتی با یک ITicketStore سفارشی وجود دارد که در قسمت «مدیریت اندازه‌ی حجم کوکی‌های ASP.NET Core Identity» با ارائه‌ی کدهای کامل آن بررسی شده‌است.