Active Directory Federation Services

از ویندوز NT و روز های اولیه Active Directory Domain Services روابط Trust یکی از قابلیت های موجود بود که در ویندوز های نسخ بعدی روز به روز نظریه پیاده سازی روابط Trust بیشتر مطرح و قابلیت های جدیدی پیدا کرد. یکی از انواع Trust که از ویندوز سرور 2003 منتشر شد، روابط Forst Trust بود. پیاده سازی Forest Trust دو جنبه قابل توجه دارد:

از ویندوز NT و روز های اولیه Active Directory Domain Services روابط Trust یکی از قابلیت های موجود بود که در ویندوز های نسخ بعدی روز به روز نظریه پیاده سازی روابط Trust بیشتر مطرح و قابلیت های جدیدی پیدا کرد. یکی از انواع Trust که از ویندوز سرور 2003 منتشر شد، روابط Forst Trust بود. پیاده سازی Forest Trust دو جنبه قابل توجه دارد:

1. لازم است یک پورت مشخص در Firewall برای ترافیک AD DS باز شود.

2. اگر تعداد روابط زیاد شود، مدیریت کار بسیار دشواری می شود.

بنابراین در بسیاری از سناریو ها، پیاده سازی روابط Trust بهترین انتخاب نیست.

دیدگاه امنیتی

همانطور که ذکر شد، مدیریت تعداد زیادیی رابطه Trust علاوه بر آنکه کار دشواری است، تاثیر بسیاری روی مکانیسیم و طراحی امنیت شبکه دارد. به طور مثال ترافیک AD DS با پروتکل LDAP روی پورت 389 TCP منتقل می شود. به طور بهتر با Secure LDAP یا LDAP/s روی پورت 636. همچنین برای انتقال ترافیک GC از 3268 و به طور بهتر 3269 استفاده می شود. (با Secure LDAP)

Firewall وظیفه دارد تا با ترافیک های نا خواسته مقابله کند. باز کردن تعداد زیادی پورت روی فایروال هیچ گاه راه حل انجام کاری نیست. در طراحی های قبلی شبکه ها؛ که از دو لایه محافظتی استفاده می شد. لایه  اول از Perimeter Nework در برابر دسترسی خارجی محافظت می کرد و لایه دوم از شبکه داخلی را از perimeter Network محافظت می کرد. (طراحی ساده، محافظه کارانه و هنوز در بسیاری از سناریو ها مناسب) Perimeter شامل سرویس هایی همچون Web Server، Mail Server, AD RMS, AD CS و… می باشد. AD DS همواره در شبکه داخلی (Internal) جای می گرفت. فایروال ایدآل خارجی تنها برخی از پورت های کلیدی را مجاز می شمرد:

1. پورت 53: برای DNS که اغلب تنها برای استفاده read-only مجوز دارد.

2.پورت 80: برای HTTP که به علت آنکه امنیت مناسبی ندارد تنها جهت دسترسی Read-Only.

3. پورت 443: برای HTTPS که با SSL یا TLS ایمن شده اند و از یک CA برای رمزنگاری اطلاعات استفاده کرده اند.

4. پورت 25: برای SMTP با یک ریسک لازم، چرا که بدون دسترسی به ایمیل هیچ کاری نمی توان کرد!!!

و به صورت ایده آل تمام پورت های دیگر باید بسته باشند. فایروال داخلی با توجه به تکنولوژی های مورد استفاده در Perimeter Network لازم است تعداد بیشتری پورت باز داشته باشد.

Active Directory Federation Services – AD FS:

با ظهور Active Directory Federation Services در ویندوز سرور 2008 باری دیگر کنترل روی شبکه داخلی از خارجی دگرگون شد. AD FS در واقع کار کردی مشابه روابط Trust را دارد اما نه با استفاده از LDAP با استفاده از HTTPS و پورت رایج 443. برای این منظور AD FS وابسته به AD CS است تا برای هر سرور در پیاده سازی AD FS یک Certificate صادر کند. AD FS همچنین با گسترش AD RMS (Active Directory Rights Management Services) باعث مدیریت ساده تر روی Partners می شود.

اساسا؛ AD FS وابسته به AD DS  داخلی هر partner است. زمانی که یک کاربر می خواهد به یک برنامه یکپارچه با AD FS دسترسی پیدا کند، AD FS درخواست را به AD DS داخلی ارجاع می دهد و اگر کاربر مجوز دسترسی لازم را داشته باشد، برای استفاده از برنامه خارجی مجوز لازم صادر می شود. مزیت این روش آن است که هر سازمان همکار (Partner) تنها لازم است که اطلاعات تعیین هویت در شبکه داخلی خودش را مدیریت کند و AD FS بقیه کار ها را انجام می دهد. به طور خلاصه؛ زمانی که نیاز به Partnership با یک سازمان دیگری وابسته به دایرکتوری داخلی باشد، AD FS پیاده سازی می شود.

به عبارت جامع تر، Active Directory Federation Services یک موتور SSO یا Single Sing-On است که امکان Authentication برای کاربران یک نرم افزار تحت وب را فراهم می آورد. SSO یک خاصیت سیستم های کنترل دسترسی است که در آن کاربر یک بار logon کرده و برای دسترسی به سایر سیستم های مربوط (و نه وابسته) نیاز به logon مجدد ندارد. استفاده از SSO مزایای بسیار زیادی همانند کاهش هزینه، افزایش بهره بری و صرفه جویی در وقت را دارد. مزایای مدیریتی AD FS بسیار مشهود است. با استفاده از AD FS نیازی به استفاده از AD LDS برای Primeter Network نیست و تنها عملیات مدیریتی روی یک دایرکتوری انجام می شود. کاربران تنها لازم است یک کلمه عبور را به یاد داشته باشند و احتمال فراموش کردن کلمه عبور کاهش می یابد. ضمن آنکه تنها یک بار کلمه عبور از کاربر سوال خواهد شد.

برای روابط B2B - Business to Business استفاده از AD FS می تواند بهترین شکل ممکن پیاده سازی باشد. معمولا  کمپانی های این سناریو ها به شکل زیر هستند (در یکی از دو دسته زیر جای می گیرند):

الف: Resource Organization : زمانی که یک کمپانی منابعی همانند یک وب سایت را در دسترس کمپانی دیگر قرار می دهد از AD FS استفاده می کند. در این حالت این چون این کمپانی Shared Resource را روی perimeter Network خود قرار می دهد، Resource Organization گفته می شود.

ب: Account Organization : زمانی که یک کمپانی در partnership با یک resource organization قرار می گیرد، یک Account Organization تلقی می شود چون؛ این کمپانی باید اکانت های کاربری را در طراحی SSO مدیریت کند تا به resource مورد نظر دسترسی پیدا کنند.

AD FS همچنین یک متد Authentication دیگری را پشتیانی می کند. در طراحی یک Web SSO کاربران می تواند از هر مکانی با استفاده از اینترنت authenticate شوند.

یک سناریو ساده و متداول

پیش از ادامه بحث جهت درک بهتر مفهوم AD FS سناریو ساده شده زیر را در نظر بگیرید. در این سناریو کاربر با مرورگر خود از اینترنت قصد دارد نرم افزار تحت وب Time Tracker متصل شود. نرم افزار Time Tracker برای تعیین هویت کاربران می تواند از DB خود استفاده کند. استفاده از DB جداگانه مشکلات و موانع متعددی همانند افزایش هزینه های پیاده سازی و نگه داری دارد. با استفاده از AD FS می توان از متد تشخیص هویت AD DS یا AD LDS بهره برد.

 

در اینجا با توجه به آنکه کاربر از اینترنت قصد دارد به Preimeter Network کمپانی متصل شود، اطلاعات ارسالی باید از Firewall عبور کند. استفاده از پورت های متداول LDAP نیازمند باز شدن پورت جدیدی روی Firewall است. در اینجا با استفاده از پورت 80 یا  443 می توان عملیات تشخیص هویت را انجام داد.

سرویس رول ها

AD FS به چهار Role Service وابسته است:
(Role Service: نرم افزار هایی هستند که عملکرد یک Role ایجاد می کنند. در زمان نصب Role بر اساس نیاز های لازم، Role Service های انتخابی نصب می شوند)

Federation Service: شامل یک یا چند federation server می شود که از یک Trust Policy استفاده می کنند. با استفاده از federation server در خواست های Authentication جهت صدور Token به دایرکتوری مورد نظر هدایت می شوند.

Federation Service Proxy: یک proxy server است برای Federation Service که معمولا در perimeter Network جای می گیرد. پروکسی اطلاعات تعیین هویت را از مرورگر (Web Browser) کاربر جمع و با استفاده از WS-Federation Passive Reqestor Profile یا WS-F PRP و به Federation Service ارجاع می دهد.

Claims-Aware Agent: یک عاما که روی یک وب سرور قرار می گیرد و امکان Query های به FS ایجاد می شود.

Windows Token-Based Agent: این سرویس رول، Token های AD FS را به Token های Windows NT معادل می کند جهت استفاده برنامه هایی که به Windows Authentication وابسته اند به جای متد های تحت وب Authentication.

* در ویندوز سرور 2003 R2 نیز AD FS پشتیبانی شده است، با این حال پشتیانی AD FS در ویندوز سرور 2008 دچار تغییرات قابل توجهی شده و بهبود های مهمی را داشته.

 

ویژگی های کلیدی AD FS:

پیش از توضیح ویژگی های مهم AD FS ابتدا یادآوری می کنم که AD FS چه چیزی نیست:

1. یک DataBase یا Directory شامل اطلاعات تعیین هویت کاربران
2. یک Extension برای Active Directory Schema
3. یک نوع رابطه Trust بین دامینی یا بین جنگلی

ویژگی های AD FS می تواند در درک دقیق و بهتر AD FS کمک کند:

1. Federation & SSO: زمانی که یک کمپانی از AD DS استفاده می کند، به خودی خود از مزایای SSO از طریق Windows Authentication در درون مرز های امنیتی سازمان بهره می برد. استفاده از Federation سبب می شود تا این مرز به گستره شبکه اینترنت بدل شود. همچنین همانطور که بیشتر گفته شد، می تواند در ارتباطات B2B نیز مورد استفاده قرار گیرد.

2.معماری قابل توسعه: AD FS از یک معماری قابل توسعه بهره می برد، به این معنا که از Security Assertion Markup Language یا SAML پشتیبانی می کند.

3. قابلیت همکاری با سرویس های تحت وب: WS-Federation این امکان را فرآهم می آورد تا محیط هایی که از مدل تعیین هویت ویندوز استفاده نمی کنند به محیط ویندوز وابسته شوند.

فرآیند تعیین هویت در AD FS

زمانی که AD FS پیاده سازی شود، فرآیند logon به یک نرم افزار تحت وب درکمپامی partner از نگاه کاربران به صورت Transparent اتفاق می افتد (فرآیندی که اتفاق می افتد اما از نگاه کاربر قابل رویت نیست). در سناریو متداول AD FS زمانی که کاربر به یک برنامه Claims-aware روی Perimeter Network کمپانی partner می خواهد متصل شود، AD FS به صورت خودکار credential لازم را فرآهم می آورد.

1. یک کاربر که روی Internal Network یا Internet است می خواهد به یک Web App دسترسی پیدا کند. این کاربر دارای یک اکانت در Account organization است.

2. Claim-Aware Agent با استفاده از Resource Federation Server مجوز دسترسی کاربر را بررسی می کند. از آنجایی که این درخواست باید از Firewall عبور کند از یک Proxy لازم است استفاده شود؛ Resource Federation Service Proxy در اینجا این وظیفه را بر عهده دارد.

3. از آنجایی که Resource Federation Server دارای یک اکانت برای کاربر نمی باشد، اما دارای یک ارتباط Federation است (Federation Relation) با Account Organization، اکانت های Federation Server در Account Ogranization را بررسی می کند. باری دیگر این فرایند باید از طریق Proxy انجام شود.

4. Federation Server در Account Organization مستقیما به AD DS متصل است تا حقوق دسترسی کاربر را از طریق LDAP دریافت کند. توجه داشته باشید در اینجا به جای AD DS می تواند AD LDS قرار گیرد.

5. Federation Server درAccount Organization برای کاربر Token لازم را می سازد.

6. Account Federation Server به Resource Federation Server جهت تصدیق دسترسی کاربر، Token را به صورت رمزنگاری شده از طریق Proxy ارسال می کند.

7. Resource Federaion Server سپس Token را Decrypt می کند و یک سیاست فیلترینگ را برای درخواست مذکور در نظر می گیرد.

8. Claims ای که فیلتر شده است، باری دیگر با Security Token به صورت Signed رمزنگاری و بسته بندی شده و به Resource Web Server ارسال می شود.

9. وب سرور که دارای یک Claim-Aware Agent است Token را  Decrypt کرده و مجوز دسترسی به Web App مطلوب صادر می شود.

10. جهت پشتیبانی از SSO وب سرور به واسطه ی AD FS Agent یک Cookie روی کامپیوتر کلاینت می سازد تا پروسه فوق لازم نباشد دوباره صورت گیرد.

 پروسه فوق پس از پیاده سازی به سهولت انجام خواهد شد، با این وجود پیاده سازی AD FS باید با توجه های خاصی صورت گیرد. هر Partner می تواند برای نگه داری اطلاعات هویت کاربران از دایرکتوری داخلی یا دایرکتوری مجزای دیگری استفاده کند. این کار مدیریت دسترسی کاربران را شاید قدری ساده تر کند. اما برای انجام کار لازم است تا یک Federation Trust پیاده سازی شود. پیاده سازی Federation Trust به آن وابسته است که هر partnet حداقل دارای یک Federation Server در شبکه خود باشد. همچنین توجه داشته باشید که از یک کامپیوتری عمومی همانند اینترنت کافه، کامپیوتر خانگی کاربر و… که عضوی از AD DS سازمان نیستند، کاربر می تواند با استفاده از یک صفحه خاص وب در AD FS مشخص کند که از کدام اکانت سازمانی استفاده شود. این صفحه وب همچنین یک Logon Screen را نیز فراهم می آورد.