یکی از شیوه های نوین و موثر برای احراز هویت کاربران در سیستم ها، شیوه ی احراز هویت بر پایه ی Claims است. روش کار این مورد را در این مقاله مورد بررسی قرار می دهیم.

برای یک برنامه عادی که در داخل یک سازمان استفاده می شود، کاربران می توانند به آسانی با استفاده از نام کاربری و رمز عبور به برنامه دسترسی پیدا کنند که این دو مورد در پایگاه داده برنامه ذخیره می شود. روند احراز هویت و سنجش درستی نام کاربری و رمز عبور همگی بر عهده خود سازمان است.

حالا تصور کنید که این برنامه هم بخواهد توسط کاربران داخلی و هم توسط کاربران خارج سازمان به کار گرفته شود. این برنامه باید هم نام کاربری و رمز عبور افراد داخلی و هم نام کاربری و رمز عبور کاربران خارجی را احراز هویت کند. این روند احراز هویت کاربران، همگی توسط سازمان باید انجام بگیرد. حالا اگر یک فرد(مثلا یک شریک تجاری) بخواهد به همین برنامه دسترسی پیدا کند چه اتفاقی می افتد؟ ایا این فرد باید به عنوان یک فرد خارج از سازمان ، وارد سایت شود و یا از نام کاربری و رمز عبور مختص افراد سازمان استفاده کند؟ اگر برنامه بر روی Cloud میزبانی شود، چه اتفاقی می افتد؟

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

چگونه این مشکل را حل کنیم؟

در اینجا ایده ی "Claims" پدید می آید که یک تکنیک یکپارچه برای مدیریت همه ی این احراز هویت ها در اختیار ما قرار می دهد. 

در دنیای دیجیتال، هر برنامه در کامپیوتر،  identity خاص خودش را دارد. این قضیه برای کاربرانی که به منابع خاصی دسترسی دارند، نیز برقرار است. هر کدام از این کاربران، یک  identity منحصر بفرد برای خودشان دارند. هنگامی که یک کاربر درخواست دسترسی به برنامه را می دهد، و نام کاربری و رمز عبور خودش را در سیستم وارد می کند، یک token توسط سرویس احراز هویت، تولید می شود که شامل Identity کاربر است. 

token شامل اطلاعاتی است درباره کاربر است.(در حقیقت، این اطلاعات را قبلا کاربر به سیستم بازگو کرده است. )

در مراحلی که در بالا بیان کردیم، سرویس احراز هویت به این صورت کار می کند که token را بر اساس نام کاربری و رمز عبوری که کاربر وارد کرده است، ایجاد می کند و آن را به صورت دیجیتالی امضا می کند. 

claim ها برای برنامه های متفاوت ، می توانند متفاوت باشند، که بستگی به نوع برنامه و داده هایی که از کاربر گرفته می شود دارد. در محیطی که ما داریم درباره ی آن صحبت می کنیم، سرویسی که این امور را انجام می دهد، STS (Security token Service) نامیده می شود.

بیایید در نظر بگیریم که یک کاربر می خواهد با استفاده از مرورگر وب و یا Rest Service می خواهد به یک برنامه دسترسی پیدا کند. بنابراین، کاربر به STS هدایت خواهد شد. مرورگر و یا client های دیگر به کاربر کمک می کنند تا وارد برنامه شود، که این کار سبب ایجاد token خواهد شد.

نقش Identity Provider

در اینجا STS فقط یک سرویس است که مرورگر را با ایجاد token یاری می کند، که در این کار از Identity Provider کمک می گیرد.  identity provider در اینجا مورد اعتماد برنامه است و برای برنامه از پیش تعریف شده است. در حقیقت، claim هایی که کاربر بیان می کند باید توسط Identity Provider مورد قبول واقع شوند ، در غیر اینصورت ، کاربر به هیچ عنوان اجازه ورود به برنامه نخواهد گرفت. میزان اعتماد و تکیه برنامه به  identity provider بستگی به معماری برنامه دارد. 

به بیان ساده ، اگر برنامه شما در داخل domain شرکت تان در حال استفاد از STS است، شرکت به منزله ی  identity provider شما است . اگر شما از یک STS token در Facebook استفاده می کنید، Facebook  ، ب منزله  identity provider شما است. 

Claimها از نگاه برنامه 

زمانی که claim ها وجود نداشته باشند، زمانی که کاربر نام کاربری و رمز عبور خودش را وارد کند، برنامه آن را بررسی و تایید می کند و اگر برای تایید، نیاز به اطلاعات بیشتری داشته باشد ، باید یک پایگاه داده مخصوص به خودش و یا اسنادی از سازمان را به کار بگیرد. در اینجا لزوم استفاده از token مشخص می شود. 

در یک روش مبتنی بر token ، برنامه به هیچ وجه، نگران این نیست که کاربر چگونه احراز هویت شده است. و برای برنامه نویسان هم نیاز نیست تا برنامه ای جداگانه بسازند تا انواع مختلفی از احراز هویت را برای کاربر انجام بدهد. 

هدف اصلی از احراز هویت مبتنی بر token این است که تایید اطلاعات کاربر برای برنامه ساده شود و برنامه به راحتی بتواند تصمیم بگیرد که کدام نقش (Role) به کدام کاربر نسبت داده شده است. قدم بسیار مهمی که باید انجام شود این است که مدیر باید، identity provider و STS  را پیکر بندی کند  تا بتواند انواع مختلفی از token را تولید کند. 

نکته ای که در اینجا باید گفته شود به این صورت نیست که یک کاربر برای  ورود به برنامه های مختلف، با وارد کردن نام کاربری و رمز عبور ، هر بار یک  digital identity مشابه دریافت کند. این identity ها از نظر ماهیت و داده با هم تفاوت خواهند داشت. 

در زمانی که با identity های متعددی سر و کار داریم، زمانی که کاربر تلاش می کند با استفاده از یک مرورگر و یا Rest Service  و یا هر client دیگری به یک برنامه دسترسی پیدا کند، برنامه claim  هایی که لازم دارد را با استفاده از Http protocol مشخص می کند. زمانی که مرورگر این مرحله را به انجام برساند، کاربر قادر خواهد بود در identity selector های متعددی ، نام کاربری و رمز عبور خودش را استفاده کند. سپس identity selector با identity provider ارتباط برقرار می کند ، که token را تولید کند و آن را به مرورگر تحویل بدهد. مرورگر چون به identity provider اعتماد دارد، این token را تایید می کند. به محض این که این token تایید شد، برنامه claim های موجود در token را بررسی می کند. 

روش مبتنی بر token الزاما دارای یک الگوی خاص برای token های تولید شده نیست. امروزه ، token ها با استفاده از فرمت های XML SAML تولید می شوند ولی می توان از فرمت های دیگری نیز استفاده کرد. 

سرویس های Active Directory Federation 

Microsoft ، سرویس های Active Directory Federation را برای پشتیبانی از احراز هویت بر اساس claim و Windows Identity Foundation فراهم کرده است.  ADFS 2.0 یک STS مبتنی بر ویندوز را پیاده سازی می کند. همان طور که از نام آن پیدا است، این مورد، یک افزونه از Active Directory Domain Services است. ADFS 2.0 یک STS را پیاده سازی می کند که token های SAML  تولید می کند. ADFS 2.0 همچنین از WCF  نیز پشتیبانی می کند. محصولات سایر شرکت ها نیز دارای این موارد مشابه می باشند. 

دسترسی کاربر به یک برنامه در Intranet 

بیایید در نظر بگیریم که یک کاربر می خواهد به یک برنامه Intranet  دسترسی داشته باشد. کاربر به برنامه وارد می شود و یک SAML token دریافت می کند. حالا، کاربر تلاش می کند به برنامه دسترسی داشته باشد، برنامه ، claim های مورد نیاز کاربر را فراهم می کند و سپس کاربر به ADFS سازمان هدایت می شود. ADFS ، مسئول تایید token است . سپس ADFS STS ، یک token  برای کاربر ایجاد می کند و آن را به کاربر تحویل می دهد. حالا client می تواند به برنامه دسترسی پیدا کند. برنامه SAML token را تایید می کند و به کاربر اجازه می دهد به برنامه دسترسی پیدا کند. 

این انتقال از AD به  ADFS  و سپس از ADFS به برنامه چرا انجام می شود؟

در اینجا ADFS به منزله ی یک  Identity provider پیکربندی شده است تا بتواند انواع مختلفی از token  که برنامه نیاز دارد را تولید کند. اگر ADFS  نباشد، معماری برنامه باید به گونه ای پیاده سازی شده باشد که برنامه بتواند وظایف آن را انجام بدهد. 

دسترسی کاربر به یک برنامه مشابه بر روی Internet

اگر همه ی اموری که در پاراگراف قبل گفتیم، بخواهد انجام شود، باید از CBA استفاده کنیم.

اگر یک کاربر از راه دور و از طریق Internet بخواهد به برنامه دسترسی پیدا کند، از کاربر درخواست می شود یکی از identity selector ها را انتخاب کند. زمانی که انتخاب کاربر انجام شد، کاربر به ADFS STS هدایت می شود تا یک token برای او ساخته شود و سپس به برنامه هدایت خواهد شد. 

احراز هویت کاربر توسط Identity provider چگونه انجام می شود؟

زمانی که یک کاربر راه دور درخواست دسترسی به برنامه را می دهد، نام کاربری و رمز عبور توسط   ADFS STS از او پرسیده می شود. سپس مطابق مراحل قبل ، چون هویت کاربر قبلا در Active Directory تایید شده است و اکنون مورد قبول است ، پس ADFS STS به Active Directory می رود و کاربر را با تولید یک token احراز هویت می کند. 

اگر کاربر های برنامه، کارکنان سازمان نباشند چه اتفاقی می افتد؟

در اینصورت از کاربران درخواست می شود با استفاده از Facebook, Gmail,  یا Google + و یا هر Identity provider دیگری به برنامه log in کنند و پروفایل آن ها در Active Directory به عنوان کاربران خارجی ایجاد خواهد شد. 

اما در هر صورت، اگر کاربران نام کاربری و رمز عبور را خودشان وارد می کنند، claim در اینجا به چه معنی است؟

نکته ای که در این جا قابل توجه است این است که اگر چندین برنامه توسط سازمان بر روی اینترنت قرار گرفته باشد، کاربران نیازی نیست  تا برای همه ی آ ن ها نام کاربری و رمز عبور وارد کنند. اگر تنها یک بار ، کاربر به یکی از برنامه وارد شود، به راحتی می تواند به برنامه های دیگر نیز دسترسی داشته باشد. در اینجا سازمان به منزله ی Identity provider برای برنامه فعالیت می کند.

آموزش asp.net mvc