مقدمه:
آیا ممکن است که سامانه‌ای فارغ از پیچیدگی‌های مربوط به احراز هویت کاربران، فقط به انجام مسئولیت‌های خود بپردازد و تمام امور مربوط به احراز هویت و نگهداری حساب‌های کاربران را به سیستم دیگری واگذار کند؟ آیا ممکن است که یک یا چند سیستم، هر نوع دانستنی مورد نیاز درباره یک کاربر را از یک مرجع مشترک و مورد اعتماد و از طریق ارتباطی امن، دریافت کنند؟
جواب این پرسشها مثبت است. اپلیکیشن‌ها می‌توانند با اتصال به یک سیستم متمرکز و اعتماد به آن، اطلاعات مورد نیاز درباره کاربرانشان را به صورت امن دریافت کنند. این اطلاعات می‌توانند هر نوع اطلاعاتی مانند نام،ایمیل، سن، شهر، سقف مجاز برای برداشت وجه، رنگ مورد علاقه و ... باشند. این اطلاعات همیشه در یک فرمت استاندارد به سیستم‌های درخواست کننده تحویل داده می‌شوند. سیستم‌های متقاضی اطلاعات کاربران، نمی‌دانند که سیستم صادر کننده‌ی این اطلاعات، هویت کاربران را با چه روشی احراز کرده‌اند. آنها فقط به این سیستم اعتماد می‌کنند و روش احراز هویت برایشان فرقی ندارد و در واقع مسئولیت احراز هویت را به سیستم دیگری تفویض کرده‌اند. بنابراین هر آنچه که مربوط به احراز هویت کاربران است به سامانه ی مجزایی سپرده می‌شود و دیگر سامانه ها به آن اعتماد می‌کنند و از کاربران می‌خواهند که برای احراز هویت ابتدا به آن سامانه مراجعه کرده و پس از احراز هویت به سامانه خدمت دهنده، وارد شوند.
این روش (Claim Base Authentication) چگونه کار می‌کند؟
این روش احراز هویت برای همه‌ی ما آشناست. با ذکر یک مثال، این روش احراز هویت را توضیح می‌دهیم. هر بار که به فرودگاه می‌روید در واقع از شبیه همین روش برای احراز هویت شما استفاده می‌شود. مسلما برای ورود به هواپیما نمی‌توانید مستقیما به گیت پرواز بروید و کارت ملی خود را نشان دهید و سوار هواپیما شوید. بلکه ابتدا باید در کانتر پرواز،کارت پرواز خود را دریافت کنید. برای دریافت کارت پرواز، مسئول مربوطه مدارک هویتی شما را چک می‌کند (Authentication). مسئول صدور کارت پرواز ممکن است به دیدن گواهینامه رانندگی شما اکتفا کند و یا از شما مدارک بیشتری مانند پاسپورت درخواست کند. پس از اینکه مدارک هویتی شما بررسی شد و عکس و چهره شما با هم تطبیق داده شد، کارت پرواز شما صادر می‌شود (Authorization). در کارت پرواز اطلاعاتی مانند شماره پرواز، ساعت پرواز،شماره صندلی، بارکد امنیتی و ... درج شده است. این کارت حاوی اطلاعات مورد نیازی است که مسئول گیت پرواز به آنها نیاز دارد. در کارت پرواز علاوه بر اطلاعاتی که روی کارت چاپ شده است، کد مغناطیسی مخصوصی هم وجود دارد که با بررسی آن مسئول گیت پرواز مطمئن می‌شود که این کارت توسط مرجع معتبر صادر شده و جعلی نیست. بنابراین این کارت دو ویژگی را با هم دارد:
· حاوی اطلاعات مسافر و اطلاعات پرواز وی است.
· کد مغناطیسی درج شده در کارت تضمین می‌کند که کارت جعل نشده است.
نکته ی دیگری که باید به آن توجه کرد این است که برای مسئول گیت پرواز اهمیت ندارد که کارت پرواز را از چه کسی دریافت کرده‌اید. همین که کارت پرواز شما معتبر باشد (تصدیق از طریق کد مغناطیسی)، مسئول مربوطه مجوز ورود به هواپیما را به شما می‌دهد.
در دنیای نرم افزار، به چنین بسته‌ای از اطلاعات، نشانه‌ی امنیتی (Security Token)، به اقلام اطلاعاتی درون نشانه، Claim و به مرجع صادر کننده‌ی آن Issuer گفته می‌شود. سامانه‌ای که برای احراز هویت کاربرانش از Claim استفاده می‌کند (claims-based application) گفته می‌شود. (شکل ۱)
درباره Claim
یک Claim یک قلم از اطلاعات توصیفی درباره‌ی کاربر (کاربر انسانی یا سامانه های کامپیوتری) است. اقلام اطلاعاتی مانند نام کاربر، ایمیل، نام مدیر، گروه‌های عضویت، نقش‌های کاربری و ... است. این اقلام اطلاعاتی الزاماً از یک پایگاه داده استخراج نمی‌شوند و مرکز صدور نشانه (توکن) می‌تواند این Claim ها را از منابع اطلاعاتی مختلف گردآوری کرده و در قالب نشانه امنیتی صادر کند.
مرجع صدور نشانه (Token) امنیتی (Issuer):
مرجع صدور توکن، سامانه‌ای است که می‌تواند به روشهای متنوعی هویت کاربر را احراز کرده و پس از آن توکن امنیتی درخواست شده را تولید و تحویل دهد. معمولا احراز هویت کاربران/سیستمها به روشهایی مانند Forms Authentication، Kerberos و یا با استفاده از Certificate انجام می‌شود. مرجع صدور توکن را می‌توان به نحوی تنظیم کرد که توکن های صادر شده از طرف دیگر مراجع صدور توکن را بپذیرد. فراهم کردن امکان پذیرش توکن از دیگر مراجع، منجر به دست یابی به قابلیت «هویت متحد» (identity federation) خواهد شد. بستر سازی برای پشتیبانی از «هویت متحد» امکان پیاده سازی قابلیت «یکبار ورود» (Single Sign On) را فراهم می‌کند.
مراجع صدور نشانه امنیتی خارج از سامانه
یک مرجع صدور نشانه درون سازمانی می تواند به دیگر مراجع صادر کننده نشانه امنیتی خارج از سازمان اعتماد کند و از آنها برای صدور نشانه امنیتی کمک بگیرد. مثلا اغلب کاربران یک سازمان که حساب کاربری در سامانه Active Directory دارند، هم زمان در سایر مراجع صدور نشانه امنیتی مانند شبکه های اجتماعی (Facebook) یا ارایه دهنده خدمات پست الکترونیکی (Gmail)، دارای حساب کاربری هم هستند. بنابراین می‌توان تمهیدی فراهم کرد که مرجع صدور نشانه‌ی امنیتی مستقر در سازمان، از نشانه‌های امنیتی صادره توسط دیگر صادرکنندگان شناخته شده و مورد اعتماد، استفاده کند. به این ترتیب کاربران نیاز نخواهند داشت تا برای استفاده از هر سامانه، یک حساب کاربری جدید ایجاد کنند و صرفا با داشتن یک حساب کاربری نزد یکی از مراجع صدور نشانه، خواهند توانست از خدمات کلیه سامانه‌هایی که به آن مرجع اعتماد دارند، استفاده کنند.
آنچه که برای سامانه‌های مبتنی بر Claim (Claims-based applications)، اهمیت دارد این است که اطلاعاتی که درباره‌ی کاربران می‌خواهند بدانند در قالب Claim دریافت کنند. برای این سامانه ها اهمیتی ندارد که اطلاعات لازم برای صدور نشانه امنیتی، در کجا ذخیره و چگونه گردآوری شده‌اند. وابسته نبودن به مکانیسم نگهداری اطلاعات کاربران، نحوه ی احراز هویت آنها و فارغ بودن از پیچیدگی ها صدور نشانه امنیتی از بزرگترین مزایای سامانه های مبتنی بر Claim است.
مایکروسافت برای پشتیبانی از این نوع خدمات، محصولات زیر را ارایه می‌دهد که نقش و روش ارتباط آنها در شکل زیر نمایش داده شده است:
- Microsoft Azure™ Access Control Service (ACS)
- Active Directory Federation Services (ADFS)
سامانه مبتنی بر Claim چگونه پیاده‌سازی می شود؟
برای پیاده سازی این سامانه ها به طور خلاصه باید ۴ گام زیر را پیمود:
۱- سامانه باید بتواند Claim ها را درک کند و قواعد کسب و کار را بر مبنای آنها سازمان دهد.
مجموعه کلاسهای Windows Identity Foundation (WIF) برای این کار تدارک دیده شده است.
۲- یک مرجع صدور نشانه امنیتی ایجاد شود یا با یک مرجع صدور برای دریافت خدمات توافق شود.
سرویس‌های ADFS یا ACS ابزار مناسبی برای این منظور هستند. همچنین در شرایطی که این سرویس‌ها پاسخگوی نیاز سازمان نباشند می‌توان بر پایه امکانات توسعه مبتنی بر بستر WIF، مرجع صدور سفارشی ایجاد کرد.
۳- سامانه باید برای اعتماد و ارتباط با مرجع صدور نشانه امنیتی، پیکربندی شود.
مهمترین مسایلی که در این مرحله باید مورد بررسی قرار گیرد شامل موارد زیر است:
- مرجع صدور توکن چه نوع Claim هایی صادر می‌کند؟
- سامانه برای بررسی صحت نشانه امنیتی، چه کلید امنیتی را باید بررسی کند؟
- کاربران سامانه برای دریافت نشانه امنیتی، باید به چه URL رجوع کنند؟
۴- مرجع صدور نشانه امنیتی را باید به نحوی پیکربندی کرد که اطلاعاتی درباره سامانه شما داشته باشد.
مرجع صدور نشانه امنیتی نیاز دارد تا اطلاعاتی درباره سامانه شما بداند. در غیر اینصورت نمی‌تواند به سامانه شما سرویس بدهد.
- سامانه‌ی درخواست کننده نشانه امنیتی (Token)، با چه آدرسی (URI) خود را به مرجع صدور معرفی می‌کند.
- انواع Claimهایی که مرجع صدور ارایه می‌دهد و نیز انوع Claim هایی که برای سامانه ضروری یا اختیاری هستند.
- آیا مرجع صدور باید نشانه امنیتی را رمز‌گذاری کند؟ اگر بله، با چه کلیدی این کار انجام می شود؟
- سامانه، نشانه امنیتی را روی چه آدرسی (URI) دریافت می‌کند؟
خلاصه:
بکارگیریClaim
باعث می‌شود تا دو موضوع احراز هویت (Authentication)
و کنترل دسترسی (Authorization) به طور
کامل از هم تفکیک شوند. در واقع مسئولیت احراز هویت به طور کلی به سامانه دیگری
واگذار می شود. به این ترتیب نگهداری اطلاعات کاربران و اعمال سیاست‌های امنیتی
برای احراز هویت کاربران به صورت یکپارچه و متمرکز انجام می‌شود. این مهمترین مزیت
استفاده از سامانه‌های مبتنی بر Claim است.
