از ویندوز NT و روز های اولیه Active Directory Domain Services روابط Trust یکی از قابلیت های موجود بود که در ویندوز های نسخ بعدی روز به روز نظریه پیاده سازی روابط Trust بیشتر مطرح و قابلیت های جدیدی پیدا کرد. یکی از انواع Trust که از ویندوز سرور ۲۰۰۳ منتشر شد، روابط Forst Trust بود. پیاده سازی Forest Trust دو جنبه قابل توجه دارد:
۱٫ لازم است یک پورت مشخص در Firewall برای ترافیک AD DS باز شود.
۲٫ اگر تعداد روابط زیاد شود، مدیریت کار بسیار دشواری می شود.
بنابراین در بسیاری از سناریو ها، پیاده سازی روابط Trust بهترین انتخاب نیست.
دیدگاه امنیتی
همانطور که ذکر شد، مدیریت تعداد زیادیی رابطه Trust علاوه بر آنکه کار دشواری است، تاثیر بسیاری روی مکانیسیم و طراحی امنیت شبکه دارد. به طور مثال ترافیک AD DS با پروتکل LDAP روی پورت ۳۸۹ TCP منتقل می شود. به طور بهتر با Secure LDAP یا LDAP/s روی پورت ۶۳۶٫ همچنین برای انتقال ترافیک GC از ۳۲۶۸ و به طور بهتر ۳۲۶۹ استفاده می شود. (با Secure LDAP)
Firewall وظیفه دارد تا با ترافیک های نا خواسته مقابله کند. باز کردن تعداد زیادی پورت روی فایروال هیچ گاه راه حل انجام کاری نیست. در طراحی های قبلی شبکه ها؛ که از دو لایه محافظتی استفاده می شد. لایه اول از Perimeter Nework در برابر دسترسی خارجی محافظت می کرد و لایه دوم از شبکه داخلی را از perimeter Network محافظت می کرد. (طراحی ساده، محافظه کارانه و هنوز در بسیاری از سناریو ها مناسب) Perimeter شامل سرویس هایی همچون Web Server، Mail Server, AD RMS, AD CS و… می باشد. AD DS همواره در شبکه داخلی (Internal) جای می گرفت. فایروال ایدآل خارجی تنها برخی از پورت های کلیدی را مجاز می شمرد:
۱٫ پورت ۵۳: برای DNS که اغلب تنها برای استفاده read-only مجوز دارد.
۲٫پورت ۸۰: برای HTTP که به علت آنکه امنیت مناسبی ندارد تنها جهت دسترسی Read-Only.
3. پورت ۴۴۳: برای HTTPS که با SSL یا TLS ایمن شده اند و از یک CA برای رمزنگاری اطلاعات استفاده کرده اند.
۴٫ پورت ۲۵: برای SMTP با یک ریسک لازم، چرا که بدون دسترسی به ایمیل هیچ کاری نمی توان کرد!!!
و به صورت ایده آل تمام پورت های دیگر باید بسته باشند. فایروال داخلی با توجه به تکنولوژی های مورد استفاده در Perimeter Network لازم است تعداد بیشتری پورت باز داشته باشد.
Active Directory Federation Services – AD FS:
با ظهور Active Directory Federation Services در ویندوز سرور ۲۰۰۸ باری دیگر کنترل روی شبکه داخلی از خارجی دگرگون شد. AD FS در واقع کار کردی مشابه روابط Trust را دارد اما نه با استفاده از LDAP با استفاده از HTTPS و پورت رایج ۴۴۳٫ برای این منظور 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 است. در اینجا با استفاده از پورت ۸۰ یا 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.
* در ویندوز سرور ۲۰۰۳ R2 نیز AD FS پشتیبانی شده است، با این حال پشتیانی AD FS در ویندوز سرور ۲۰۰۸ دچار تغییرات قابل توجهی شده و بهبود های مهمی را داشته.
ویژگی های کلیدی AD FS:
پیش از توضیح ویژگی های مهم AD FS ابتدا یادآوری می کنم که AD FS چه چیزی نیست:
۱٫ یک DataBase یا Directory شامل اطلاعات تعیین هویت کاربران
۲٫ یک Extension برای Active Directory Schema
3. یک نوع رابطه Trust بین دامینی یا بین جنگلی
ویژگی های AD FS می تواند در درک دقیق و بهتر AD FS کمک کند:
۱٫ Federation & SSO: زمانی که یک کمپانی از AD DS استفاده می کند، به خودی خود از مزایای SSO از طریق Windows Authentication در درون مرز های امنیتی سازمان بهره می برد. استفاده از Federation سبب می شود تا این مرز به گستره شبکه اینترنت بدل شود. همچنین همانطور که بیشتر گفته شد، می تواند در ارتباطات B2B نیز مورد استفاده قرار گیرد.
۲٫معماری قابل توسعه: AD FS از یک معماری قابل توسعه بهره می برد، به این معنا که از Security Assertion Markup Language یا SAML پشتیبانی می کند.
۳٫ قابلیت همکاری با سرویس های تحت وب: WS-Federation این امکان را فرآهم می آورد تا محیط هایی که از مدل تعیین هویت ویندوز استفاده نمی کنند به محیط ویندوز وابسته شوند.
فرآیند تعیین هویت در AD FS
زمانی که AD FS پیاده سازی شود، فرآیند logon به یک نرم افزار تحت وب درکمپامی partner از نگاه کاربران به صورت Transparent اتفاق می افتد (فرآیندی که اتفاق می افتد اما از نگاه کاربر قابل رویت نیست). در سناریو متداول AD FS زمانی که کاربر به یک برنامه Claims-aware روی Perimeter Network کمپانی partner می خواهد متصل شود، AD FS به صورت خودکار credential لازم را فرآهم می آورد.
۱٫ یک کاربر که روی Internal Network یا Internet است می خواهد به یک Web App دسترسی پیدا کند. این کاربر دارای یک اکانت در Account organization است.
۲٫ Claim-Aware Agent با استفاده از Resource Federation Server مجوز دسترسی کاربر را بررسی می کند. از آنجایی که این درخواست باید از Firewall عبور کند از یک Proxy لازم است استفاده شود؛ Resource Federation Service Proxy در اینجا این وظیفه را بر عهده دارد.
۳٫ از آنجایی که Resource Federation Server دارای یک اکانت برای کاربر نمی باشد، اما دارای یک ارتباط Federation است (Federation Relation) با Account Organization، اکانت های Federation Server در Account Ogranization را بررسی می کند. باری دیگر این فرایند باید از طریق Proxy انجام شود.
۴٫ Federation Server در Account Organization مستقیما به AD DS متصل است تا حقوق دسترسی کاربر را از طریق LDAP دریافت کند. توجه داشته باشید در اینجا به جای AD DS می تواند AD LDS قرار گیرد.
۵٫ Federation Server درAccount Organization برای کاربر Token لازم را می سازد.
۶٫ Account Federation Server به Resource Federation Server جهت تصدیق دسترسی کاربر، Token را به صورت رمزنگاری شده از طریق Proxy ارسال می کند.
۷٫ Resource Federaion Server سپس Token را Decrypt می کند و یک سیاست فیلترینگ را برای درخواست مذکور در نظر می گیرد.
۸٫ Claims ای که فیلتر شده است، باری دیگر با Security Token به صورت Signed رمزنگاری و بسته بندی شده و به Resource Web Server ارسال می شود.
۹٫ وب سرور که دارای یک Claim-Aware Agent است Token را Decrypt کرده و مجوز دسترسی به Web App مطلوب صادر می شود.
۱۰٫ جهت پشتیبانی از SSO وب سرور به واسطه ی AD FS Agent یک Cookie روی کامپیوتر کلاینت می سازد تا پروسه فوق لازم نباشد دوباره صورت گیرد.
پروسه فوق پس از پیاده سازی به سهولت انجام خواهد شد، با این وجود پیاده سازی AD FS باید با توجه های خاصی صورت گیرد. هر Partner می تواند برای نگه داری اطلاعات هویت کاربران از دایرکتوری داخلی یا دایرکتوری مجزای دیگری استفاده کند. این کار مدیریت دسترسی کاربران را شاید قدری ساده تر کند. اما برای انجام کار لازم است تا یک Federation Trust پیاده سازی شود. پیاده سازی Federation Trust به آن وابسته است که هر partnet حداقل دارای یک Federation Server در شبکه خود باشد. همچنین توجه داشته باشید که از یک کامپیوتری عمومی همانند اینترنت کافه، کامپیوتر خانگی کاربر و… که عضوی از AD DS سازمان نیستند، کاربر می تواند با استفاده از یک صفحه خاص وب در AD FS مشخص کند که از کدام اکانت سازمانی استفاده شود. این صفحه وب همچنین یک Logon Screen را نیز فراهم می آورد.
طراحی AD FS
بر اساس نوع ارتباط B2B، سه روش طراحی مختلف در معماری AD FS می توان اتخاذ کرد.
۱٫ Federated Web SSO: متداول ترین و رایج ترین سناریو این گزینه است. این مدل معمولا به شکل پلی روی Firewall های مختلف عمل می کند و تنها ارتباط Trust موجود یک Federation trust است که همواره به شکل One-way (یک طرفه) از Resource Organization به Account Oranization است. (مشابه شکل پیشین در قسمت، نحوه تعیین هویت)
۲٫ Federated Web SSO با Forset trust: در این مدل سازمان از دو جنگل AD DS استفاده می کند. اولی برای شبکه داخلی که به آن به اختصار “جنگل داخلی” می گوییم و دیگری برای شبکه خارجی که به آن “جنگل خارجی” می گوییم. جنگل خارجی در واقع شامل perimeter network می شود یا روی آن واقع است. یک رابطه Trust در این حالات بین جنگل داخلی و جنگل خارجی ایجاد می شود که اغلب به صورت one-way (یک طرفه) کفایت می کند. همچنین یک Federation Trust از Resource Federation Server (در perimeter network) به Account Federation Server (در شبکه داخلی) ایجاد می گردد. تا کنون کاربران داخلی توانستند به Web App موجود روی perimeter network دسترسی داشته باشند. برای کاربران خارجی، در جنگل خارجی دارای یک اکانت هستند.
تذکر: هر یک از چهار رول اضافی Active Directory یعنی AD LDS، AD CS، AD RMS و AD FS به هدف افزایش اختیارات و توانمندی های شبکه داخلی ایجاد می شوند. افزودن یک جنگل AD DS دیگر کاری است که باید بسیار با دقت صورت گیرد و تا حد ممکن از آن پرهیز کرد. بر خلاف تصور ظاهری برخی افراد، امنیت در حالت دو، در وضعیت نا مناسب تری از وضعیت یک است. توجه داشته باشید که برقراری یک Forest Trust به معنای باز شدن یک پورت روی فایروال است که معمولا بسته است.
3. Web SSO: زمانی که تمام کاربران روی شبکه خارجی اند و روی شبکه داخلی دارای اکانت نیستند، باید تنها Web SSO پیاده سازی شود. Web SSO باعث می شود تا کاربران برای استفاده از چند Web App مختلف تنها لازم باشد یک بار Login کنند. در این حالات لازم است تا وب سرور ها دارای دو Network Interface Card یا NIC باشند که یکی از کارت شبکه ها به داخلی و دیگری به شبکه خارجی متصل باشد. همچنین این شرط برای Federation Proxy Server نیز بر قرار است. مشابه شکل زیر
سناریو های متداول و مناسب شماره ۱ و ۳ هستند. به صورت ایده آل تمام کاربران Web App روی AD DS دارای اکانت هستند.
آشنایی با اجزاء AD FS
جدا از سرویس رول ها که بحث شد، تکنولوژی AD FS به اجزا و مولفه های بسیاری وابسته است از جمله:
۱٫ Claims
2. Cookies
3. Certificates
جهت درک بهتر سرویس AD FS لازم است تا با این سه مولفه فوق و نقش آن ها در AD FS آشنا شویم.
Claims
در ساده ترین حالت می توان گفت، Claim ها (اداعا نامه ها) توضیحاتی است که هر شریک (Partner) در Federation Relation در مورد کاربران ارائه می دهد. به طور مثال، نام کاربر، عضویت در گروه ها، مجوز های خاص، کلید Certificate ها و… . Claims در واقع پایه و اساس Authorization در AD FS است. ۳ راه مختلف برای در نظر گرفتن یک Claim وجود دارد:
۱٫ Account Federation Server می تواند از دایرکتوری داخلی یک Query بگیرد و Claims را برای Resource Organization فراهم آورد.
۲٫ Acount Organization می تواند برای Resource Federation Server آن ها را فراهم آورد و پس از فیلتر شدن Claims کاربر می تواند به Web App دسترسی پیدا کند.
۳٫ Federation Service از دایرکتوری یک Query برای Claims می گیرد و آن ها را پس از فیلتر شدن Claims کاربر می تواند به Web App دسترسی پیدا کند.
سه نوع مختلف Claims در AD FS پشتیبانی می شوند:
۱٫ Claims های نوع Identity (اداعا نامه های هویتی): شامل یک User Principal Name یا UPN است که بیانگر اکانت کاربری User در قالبی شبیه به ایمیل است همانند erfan@contoso.com. به یاد داشته باشید چنانچه چند UPN مختلف لازم است تنها امکان قرار گیری یکی از آن ها در این نوع Claim است، اگر به چند UPN نیاز است باید از Custom Claims استفاده شود. همچنین می تواند یک ایمیل آدرس باشد همانند erfan@contosomail.com. همانند UPN تنها شامل یک مورد می تواند باشد. همچنین می تواند از رشته دلخواه استفاده کرد. توجه شود در این حالت هیچ متدی برای تصدیق یکتا بودن آن رشته وجود ندارد، بنابراین با احتیاط از این گزینه استفاده شود.
۲٫ Claims های نوع Group: گروه های کاربری که کاربر در آن عضو است می تواند در یک Claim معین شوند.
۳٫ Claim های نوع Custom: چنانچه اطلاعات خاص دیگر لازم باشد همانند شماره پرسنلی از این گزینه می توان استفاده شود.
Cookies
AD FS به اضافه ی Claims از Cookies نیز استفاده می کند. AD FS از Cookies برای Authentication کاربر استفاده می کند. Cookie روی Browser کاربر (در محل فیزیکی تعیین شده در Browser) جای می گیرد تا از SSO پشتیبانی به عمل آید. Cookie در واقع تمام Claim های مربوط به کاربر را شامل می شود تا در دفعات استفاده بعدی کاربر نیاز به طی کردن فرآیند تعیین هویت را نداشته باشد. Web Agent و Federation Server هر دو باهم Cookies ها را صادر می کنند تا از قرار گیری Public Key و Private Key روی یک سرور جلوگیری به عمل آید. توجه داشته باشید که Cookie اما رمز نگاری شده نیست. این یک دلیل مهم است برای آنکه تمام ارتباطات از طریق TLS یا SSL صورت گیرد.
در AD FS دو دسته Cookie مختلف صادر می شود:
۱٫Account Partner Cookie: همانطور که گفته شد، در طی مرحله تعیین هویت یک Cookie صادر می شود تا کاربر دوباره لازم نباشد فرآیند تعیین هویت را طی کند. این Cookie به صورت Signed یا رمزنگاری شده نیست.
۲٫ Sign-Out Cookie : هر زمان که Federatin Services یک Token صادر می کند Resource Partner یک Sign Out Cookie می سازد.
Certificates
برای امنیت ارتباط AD FS به AD CS جهت صدور انواع Certificate هایی که استفاده می کند وابسته است.
۱٫ Federation Server: در Federation Server باید هم Server Authentication Certificate و هم Token-Signing Certificate نصب شده باشد.
۲٫ Federation Server Proxy: در Federation Server Proxy لازم است تا Server Authentication Certificate نصب شده باشد.
۳٫ AD FS Web Agent: در Web Agent نیز باید Server Authentication Certificate نصب شده باشد.
منبع:
http://www.erfantaheri.com/2010/04/active-directory-federation-services.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+port80+%28Port+80%29
